CUBRID HA¶

노드와 그룹¶

노드는 CUBRID HA를 구성하는 논리적인 단위로, 노드는 상태에 따라 마스터 노드(master node), 슬레이브 노드(slave node), 레플리카 노드(replica node) 등으로 나눈다.

• 마스터 노드: 복제의 대상이 되는 노드로, 액티브 서버를 사용한 읽기, 쓰기 등 모든 서비스를 제공한다.
• 슬레이브 노드: 마스터 노드와 동일한 내용을 갖는 노드로, 마스터 노드의 변경이 자동으로 반영된다. 스탠바이 서버를 사용한 읽기 서비스를 제공하며 마스터 노드 장애 시 failover가 일어난다.
• 레플리카 노드: 마스터 노드와 동일한 내용을 갖는 노드로, 마스터 노드의 변경이 자동으로 반영된다. 스탠바이 서버를 사용한 읽기 서비스를 제공하며 마스터 노드 장애 시 failover가 일어나지 않는다.

CUBRID HA 그룹은 위와 같은 노드들로 이루어지며, 그룹의 멤버는 cubrid_ha.conf 의 ha_node_list 및 ha_replica_list 로 설정할 수 있다. 그룹 내의 노드들은 동일한 내용을 가지며, 주기적으로 상태 확인 메시지를 주고 받고 마스터 노드에 장애가 발생하면 failover가 일어난다.

노드에는 마스터 프로세스(cub_master), 데이터베이스 서버 프로세스(cub_server), 복제 로그 복사 프로세스(copylogdb) 및 복제 로그 반영 프로세스(applylogdb) 등이 포함된다.

프로세스¶

CUBRID HA 노드는 하나의 마스터 프로세스(cub_master), 하나 이상의 데이터베이스 서버 프로세스(cub_server), 하나 이상의 복제 로그 복사 프로세스(copylogdb), 하나 이상의 복제 로그 반영 프로세스(applylogdb)로 이루어져 있다. 하나의 데이터베이스를 설정하면 데이터베이스 서버 프로세스, 복제 로그 복사 프로세스, 복제 로그 반영 프로세스가 구동된다. 복제 로그의 복사와 반영은 서로 다른 프로세스에 의해 수행되므로 복제 반영의 지연은 실행 중인 트랜잭션에 영향을 주지 않는다.

• 마스터 프로세스(cub_master) : heartbeat 메시지를 주고 받으며 CUBRID HA 내부 관리 프로세스들을 제어한다.
• 데이터베이스 서버 프로세스(cub_server) : 사용자에게 읽기, 쓰기 등의 서비스를 제공한다. 자세한 내용은 서버 를 참고한다.
• 복제 로그 복사 프로세스(copylogdb) : 그룹 내의 모든 트랜잭션 로그를 복사한다. 복제 로그 복사 프로세스가 대상 노드의 데이터베이스 서버 프로세스에 트랜잭션 로그를 요청하면, 해당 데이터베이스 서버 프로세스는 적절한 로그를 전달한다. 트랜잭션 로그가 복사되는 위치는 cubrid_ha.conf의 ha_copy_log_base로 설정할 수 있다. 복사된 복제 로그의 정보는 cubrid applyinfo 유틸리티로 확인할 수 있다. 복제 로그 복사는 SYNC, ASYNC의 두 가지 모드가 있으며, 모드는 cubrid_ha.conf의 ha_copy_sync_mode로 설정할 수 있다. 모드에 대한 자세한 내용은 로그 다중화 를 참고한다.

• 복제 로그 반영 프로세스(applylogdb) : 복제 로그 복사 프로세스에 의해 복사된 로그를 노드에 반영한다. 반영한 복제 정보는 내부 카탈로그(db_ha_apply_info)에 저장하며, 이 정보는 cubrid applyinfo 유틸리티로 확인할 수 있다.

서버¶

서버란 데이터베이스 서버 프로세스를 논리적으로 표현하는 단어로, 상태에 따라 액티브 서버(active server), 스탠바이 서버(standby server)로 나눈다.

• 액티브 서버 : 마스터 노드에 속하는 서버로, active 상태이다. 액티브 서버는 사용자에게 읽기, 쓰기 등 모든 서비스를 제공한다.
• 스탠바이 서버 : 마스터 노드 외의 노드에 속하는 서버로, standby 상태이다. 스탠바이 서버는 사용자에게 읽기 서비스만을 제공한다.

서버 상태는 노드 상태에 따라 변경된다. cubrid changemode 유틸리티를 이용하면 서버 상태를 조회할 수 있다. maintenance 모드는 운영 편의를 위한 것으로, cubrid changemode 유틸리티를 통해 변경할 수 있다.

• active : 일반적으로 마스터 노드에서 실행 중인 서버들은 active 상태이다. 읽기, 쓰기 등 모든 서비스를 제공한다.
• standby : 슬레이브 노드 또는 레플리카 노드에서 실행 중인 서버들은 standby 상태이다. 읽기 서비스만을 제공한다.
• maintenance : 운영 편의를 위해 수동으로 변경 가능한 상태로, 로컬 호스트의 csql만 접속할 수 있으며, 사용자에게는 서비스를 제공할 수 없다.
• to-be-active : 스탠바이 서버가 failover 등의 이유로 인해 액티브 서버가 되기 전의 상태이다. 기존의 마스터 노드로부터 받은 트랜잭션 로그를 자신의 서버에 반영하는 등 액티브 서버가 되기 위한 준비를 한다. 해당 상태의 노드에는 SELECT 질의만 수행할 수 있다.
• 기타: 내부적으로 사용하는 상태이다.

노드 상태가 변경되면 cub_master 프로세스 로그와 cub_server 프로세스 로그에 각각 다음과 같은 에러 메시지가 저장된다. 단, cubrid.conf에서 error_log_level의 값이 error 이하인 경우에 저장된다.

• cub_master 프로세스의 로그 정보는 $CUBRID/log/<hostname>_master.err 파일에 저장되며 다음의 내용이 기록된다.

  HA generic: Send changemode request to the server. (state:1[active], args:[cub_server demodb ], pid:25728).
  HA generic: Receive changemode response from the server. (state:1[active], args:[cub_server demodb ], pid:25728).
  

• cub_server 프로세스의 로그 정보는 $CUBRID/log/server/<db_name>_<date>_<time>.err 파일에 저장되며 다음의 내용이 기록된다.

  Server HA mode is changed from 'to-be-active' to 'active'.
  

heartbeat 메시지¶

HA 기능을 제공하기 위한 핵심 구성 요소로, 마스터 노드, 슬레이브 노드, 레플리카 노드가 다른 노드의 상태를 감시하기 위해 주고 받는 메시지이다. 마스터 프로세스는 그룹 내의 모든 마스터 프로세스와 주기적으로 heartbeat 메시지를 주고 받는다. heartbeat 메시지는 cubrid_ha.conf 의 ha_port_id 파라미터에 설정된 UDP 포트로 주고 받는다. heartbeat 메시지 주기는 내부적으로 설정된 값을 따른다.

마스터 노드의 장애가 감지되면 슬레이브 노드로 failover가 이루어진다.

failover와 failback¶

failover란, 마스터 노드에 장애가 발생하여 서비스를 제공할 수 없는 상태가 되면 우선순위가 가장 높은 슬레이브 노드가 자동으로 마스터 노드가 되는 것이다. 마스터 프로세스는 수집한 CUBRID HA 그룹 내의 노드들의 정보를 바탕으로 스코어를 계산하여 적절한 시점에 해당 프로세스가 속한 노드의 상태를 마스터 노드로 변경하고, 관리 프로세스에 변경된 상태를 전파한다.

failback은 마스터 노드였던 장애 노드가 복구되면 자동으로 다시 마스터 노드가 되는 것이며, CUBRID HA는 서버의 failback을 지원하지 않는다.

heartbeat 메시지가 정상적으로 전달되지 않으면 failover가 일어나므로, 네트워크가 불안정한 환경에서는 장애가 발생하지 않아도 failover가 일어날 수 있다. 이와 같은 상황에서 failover가 일어나는 것을 막기 위해 ha_ping_hosts 를 설정할 수 있다. ha_ping_hosts 를 설정하면, heartbeat 메시지가 정상적으로 전달되지 못했을 때 ha_ping_hosts 로 설정한 노드로 ping 메시지를 보내서 원인이 네트워크 불안정인지 확인하는 절차를 거친다. ha_ping_hosts 설정에 대한 좀 더 자세한 설명은 cubrid_ha.conf 를 참고한다.

브로커 모드¶

브로커는 DB 서버에 Read Write, Read Only, Standby Only 이렇게 세 가지 모드 중 한 가지로 접속할 수 있으며, 사용자가 브로커 모드를 설정할 수 있다.

브로커는 DB 서버 연결 순서에 의해 연결을 시도하여 자신의 모드에 맞는 DB 서버를 선택하여 연결한다. 조건이 맞지 않아 연결되지 않으면 다음 순서의 연결을 시도하고, 모든 순서를 수행해도 적절한 DB 서버를 찾지 못하면 해당 브로커는 DB 서버 연결에 실패한다.

브로커 모드 설정 방법은 cubrid_broker.conf를 참고한다.

DB 서버 연결은 cubrid_broker.conf의 PREFERRED_HOSTS, CONNECT_ORDER와 MAX_NUM_DELAYED_HOSTS_LOOKUP 파라미터의 영향을 받는다. 이들에 의한 영향은 브로커와 DB 연결을 참고한다.

다음은 위의 파라미터들을 설정하지 않은 경우에 대한 설명이다.

Read Write

"ACCESS_MODE=RW"

읽기, 쓰기 서비스를 제공하는 브로커이다. 이 브로커는 일반적으로 액티브 서버에 연결하며, 연결 가능한 액티브 서버가 없으면 일시적으로 스탠바이 서버에 연결한다. 따라서 Read Write 브로커는 일시적으로 스탠바이 서버와 연결될 수 있다.

일시적으로 스탠바이 서버와 연결되면 트랜잭션이 끝날 때마다 스탠바이 서버와 연결을 끊고, 다음 트랜잭션이 시작되면 다시 액티브 서버와 연결을 시도한다. 스탠바이 서버와 연결되면 읽기 서비스만 가능하며, 쓰기 요청에 대해서는 서버에서 오류가 발생한다.

다음 그림은 db-host 설정을 통해 호스트에 연결하는 예이다.

databases.txt의 db-host가 node B:node C:node A 순이므로, B, C, A 순으로 접속을 시도한다. 이때 db-host에 명시된 "node B:node C:node A"는 /etc/hosts 파일에 정의된 실제 호스트 이름이다.

• Example 1. node B는 비정상 종료된 상태이고, node C는 standby 상태이며, node A는 active 상태이다. 따라서 최종적으로 node A와 연결한다.
• Example 2. node B는 비정상 종료된 상태이고, node C는 active 상태이다. 따라서 최종적으로 node C와 연결한다.

Read Only

"ACCESS_MODE=RO"

읽기 서비스를 제공하는 브로커이다. 이 브로커는 가능한 스탠바이 서버에 연결하며, 스탠바이 서버가 없으면 액티브 서버에 연결한다. 따라서 Read Only 브로커는 일시적으로 액티브 서버와 연결될 수 있다.

액티브 서버와 연결된 후 RECONNECT_TIME 설정 시간이 지나면 연결을 끊고 재연결을 시도한다. 또는 cubrid broker reset 명령을 실행하여 기존 연결을 끊고 새롭게 스탠바이 서버에 연결할 수 있다. Read Only 브로커에 쓰기 요청이 전달되면 브로커에서 오류가 발생하므로, 액티브 서버와 연결되어도 읽기 서비스만 가능하다.

다음 그림은 db-host 설정을 통해 호스트에 연결하는 예이다.

databases.txt의 db-host가 node A:node B:node C 순이므로, A, B, C 순으로 접속을 시도한다. 이때 db-host에 명시된 "node A:node B:node C"는 /etc/hosts 파일에 정의된 실제 호스트 이름이다.

• Example 1. node A는 active 상태이고, node B는 standby 상태이다. 따라서 최종적으로 node B와 연결된다.
• Example 2. node A는 active 상태이고, node B는 비정상 종료된 상태이며, node C는 standby 상태이다. 따라서 최종적으로 node C와 연결된다.
• Example 3. node A는 active 상태이고, node B와 node C는 비정상 종료된 상태이다. 따라서 최종적으로 node A와 연결된다.

Standby Only

"ACCESS_MODE=SO"

읽기 서비스를 제공하는 브로커이다. 이 브로커는 스탠바이 서버에 연결하며, 스탠바이 서버가 없으면 서비스를 제공하지 않는다.

다음 그림은 db-host 설정을 통해 호스트에 연결하는 예이다.

databases.txt의 db-host가 node A:node B:node C 순이므로, A, B, C 순으로 접속을 시도한다. 이때 db-host에 명시된 "node A:node B:node C"는 /etc/hosts 파일에 정의된 실제 호스트 이름이다.

• Example 1. node A는 active 상태이고, node B는 standby 상태이다. 따라서 최종적으로 node B와 연결된다.
• Example 2. node A는 active 상태이고, node B는 비정상 종료된 상태이며, node C는 standby 상태이다. 따라서 최종적으로 node C와 연결된다.
• Example 3. node A는 active 상태이고, node B와 node C는 비정상 종료된 상태이다. 따라서 최종적으로 어떤 노드와도 연결되지 않는다. 이 부분이 Read Only 브로커와의 차이점이다.

서버 이중화¶

서버 이중화란 CUBRID HA 기능을 제공하기 위해 물리적인 하드웨어 장비를 중복으로 구성하여 시스템을 구축하는 것이다. 이러한 구성을 통해 하나의 장비에 장애가 발생해도 응용 프로그램에서는 지속적인 서비스를 제공할 수 있다.

서버 failover

브로커는 서버의 접속 순서를 정의하고 그 순서에 따라 서버에 접속한다. 접속한 서버에 장애가 발생하면 브로커는 다음 순위로 설정된 서버에 접속하며, 응용 프로그램에서는 별도의 처리가 필요 없다. 브로커가 다음 서버에 접속할 때의 동작은 브로커의 모드에 따라 다를 수 있다. 서버의 접속 순서 및 브로커 모드의 설정 방법은 cubrid_broker.conf를 참고한다.

서버 failback

CUBRID HA는 자동으로 서버 failback을 지원하지 않는다. 따라서 failback을 수동으로 적용하려면 비정상 종료되었던 마스터 노드를 복구하여 슬레이브 노드로 구동한 후, failover로 인해 슬레이브에서 마스터로 역할이 바뀐 노드를 의도적으로 종료하여 다시 각 노드의 역할을 서로 바꾼다.

예를 들어 nodeA가 마스터, nodeB가 슬레이브일 때 failover 이후에는 역할이 바뀌어 nodeB가 마스터, nodeA가 슬레이브가 된다. nodeB를 종료(cubrid heartbeat stop)한 후, nodeA가 마스터, 즉 노드 상태가 active로 바뀌었는지 확인(cubrid heartbeat status) 한다. 그리고 나서 nodeB를 시작(cubrid heartbeat start) 하면, nodeB는 슬레이브가 된다.

브로커 이중화¶

CUBRID는 3-tier DBMS로, 응용 프로그램과 데이터베이스 서버를 중계하는 역할을 수행하는 브로커라는 미들웨어가 있다. CUBRID HA 기능을 제공하기 위해 브로커도 물리적인 하드웨어를 중복으로 구성하여, 하나의 브로커에 장애가 발생해도 응용 프로그램에서는 지속적인 서비스를 제공할 수 있다.

브로커 이중화의 구성은 서버 이중화의 구성에 따라 결정되는 것이 아니며, 사용자의 선호에 맞게 변형이 가능하다. 또한, 별도의 장비로 분리가 가능하다.

브로커의 failover, failback 기능을 사용하려면 JDBC, CCI 또는 PHP의 접속 URL에 altHosts 속성을 추가해야 한다. 이에 대한 설명은 JDBC 설정, CCI 설정 또는 PHP 설정을 참고한다.

브로커를 설정하려면 cubrid_broker.conf 파일을 설정해야 하고, 데이터베이스 서버의 failover 순서를 설정하려면 databases.txt 파일을 설정해야 한다. 이에 대한 설명은 브로커 설정, 시작 및 확인을 참고한다.

다음은 2개의 Read Write(RW) 브로커를 구성한 예이다. application URL의 첫 번째 접속 브로커를 broker B1 으로 하고 두 번째 접속 브로커를 broker B2 로 설정하면, application이 broker B1 에 접속할 수 없는 경우 broker B2 에 접속하게 된다. 이후 broker B1 이 다시 접속 가능해지면 application은 broker B1 에 재접속하게 된다.

다음은 마스터 노드, 슬레이브 노드의 각 장비 내에 Read Write(RW) 브로커와 Read Only(RO) 브로커를 구성한 예이다. app1과 app2 URL의 첫 번째 접속은 각각 broker A1 (RW), broker B2 (RO) 이고, 두 번째 접속(altHosts)은 각각 broker A2 (RO), broker B1 (RW)이다. nodeA 를 포함한 장비가 고장나면, app1과 app2는 nodeB 를 포함한 장비의 브로커에 접속한다.

다음은 브로커 장비를 별도로 구성하여 Read Write 브로커 한 개, Preferred Host Read Only 브로커 두 개를 두고, 한 개의 마스터 노드와 두 개의 슬레이브 노드를 구성한 예이다. Preferred Host Read Only 브로커들은 각각 nodeB 와 nodeC 에 연결함으로써 읽기 부하를 분산하였다.

브로커 failover

브로커 failover는 시스템 파라미터의 설정에 의해 자동으로 failover되는 것이 아니며, JDBC, CCI, PHP 응용 프로그램에서는 접속 URL의 altHosts에 브로커 호스트들을 설정해야 브로커 failover가 가능하다. 설정한 우선순위가 가장 높은 브로커에 접속하고, 접속한 브로커에 장애가 발생하면 접속 URL에 다음 순위로 설정한 브로커에 접속한다. 응용 프로그램에서는 접속 URL의 altHosts를 설정하는 것 외에는 별도의 처리가 필요 없으며, JDBC, CCI, PHP 드라이버 내부에서 처리한다.

브로커 failback

브로커 failover 이후 장애 브로커가 복구되면 기존 브로커와 접속을 끊고 이전에 연결했던 우선순위가 가장 높은 브로커에 다시 접속한다. 응용 프로그램에서는 별도의 처리가 필요 없으며, JDBC, CCI, PHP 드라이버 내부에서 처리한다. 브로커 failback을 수행하는 시간은 JDBC 접속 URL에 설정한 값을 따른다. 이에 대한 설명은 JDBC 설정을 참고한다.

로그 다중화¶

CUBRID HA는 CUBRID HA 그룹에 포함된 모든 노드에 트랜잭션 로그를 복사하고 이를 반영함으로써 CUBRID HA 그룹 내의 모든 노드를 동일한 DB로 유지한다. CUBRID HA의 로그 복사 구조는 마스터 노드와 슬레이브 노드 사이의 상호 복사 형태로, 전체 로그의 양이 많아지는 단점이 있으나 체인 형태의 복사 구조보다 구성 및 장애 처리 측면에서 유연하다는 장점이 있다.

트랜잭션 로그를 복사하는 모드는 SYNC, ASYNC의 두 가지가 있으며, 사용자가 cubrid_ha.conf로 설정할 수 있다.

SYNC 모드

트랜잭션이 커밋되면, 발생한 트랜잭션 로그가 슬레이브 노드에 복사되어 파일에 저장되고 이에 대한 성공 여부를 전달받은 후에 트랜잭션 커밋이 완료된다. 따라서 ASYNC 모드에 비해 커밋 수행 시간이 길어질 수 있지만, failover가 발생해도 복사된 트랜잭션 로그는 스탠바이 서버에 반영되어 있음을 보장할 수 있으므로 가장 안전하다.

ASYNC 모드

트랜잭션이 커밋되면, 슬레이브 노드로 트랜잭션 로그가 전송 완료되었는지 확인하지 않고 커밋이 완료된다. 따라서 마스터 노드에서 커밋이 완료된 트랜잭션이 슬레이브 노드에 반영되지 못하는 경우가 발생할 수 있다.

ASYNC 모드는 로그 복제로 인한 커밋 수행 시간 지연은 거의 없으므로 성능상 유리하지만, 노드 간의 데이터가 완전히 일치하지 않을 수 있다.

준비¶

구성도

CUBRID HA를 처음 접하는 사용자가 CUBRID HA를 쉽게 사용할 수 있도록 아래 그림과 같이 간단하게 구성된 CUBRID HA를 설정하는 과정을 설명한다.

사양

마스터 노드와 슬레이브 노드로 사용할 장비에는 Linux와 CUBRID 2008 R2.2 이상 버전이 설치되어 있어야 한다. CUBRID HA는 Windows를 지원하지 않는다.

CUBRID HA 구성 장비 사양

데이터베이스 생성 및 서버 설정¶

데이터베이스 생성

CUBRID HA에 포함할 데이터베이스를 모든 CUBRID HA 노드에서 동일하게 생성한다. 데이터베이스 생성 옵션은 필요에 따라 적절히 변경한다.

[nodeA]$ cd $CUBRID_DATABASES
[nodeA]$ mkdir testdb
[nodeA]$ cd testdb
[nodeA]$ mkdir log
[nodeA]$ cubrid createdb -L ./log testdb en_US
Creating database with 512.0M size. The total amount of disk space needed is 1.5G.

CUBRID 9.2

[nodeA]$

cubrid.conf

$CUBRID/conf/cubrid.conf 의 ha_mode 를 모든 HA 노드에 동일하게 설정한다. 특히, 로깅 관련 파라미터인 log_max_archives 와 force_remove_log_archives, HA 관련 파라미터인 ha_mode 의 설정에 주의한다.

# Service parameters
[service]
service=server,broker,manager

# Common section
[common]
service=server,broker,manager

# Server parameters
server=testdb
data_buffer_size=512M
log_buffer_size=4M
sort_buffer_size=2M
max_clients=100
cubrid_port_id=1523
db_volume_size=512M
log_volume_size=512M

# HA 구성 시 추가 (Logging parameters)
log_max_archives=100
force_remove_log_archives=no

# HA 구성 시 추가 (HA 모드)
ha_mode=on

cubrid_ha.conf

$CUBRID/conf/cubrid_ha.conf 의 ha_port_id, ha_node_list, ha_db_list 를 모든 HA 노드에 동일하게 설정한다. 다음 예에서 마스터 노드의 호스트 이름은 nodeA, 슬레이브 노드의 호스트 이름은 nodeB라고 가정한다.:

[common]
ha_port_id=59901
ha_node_list=cubrid@nodeA:nodeB
ha_db_list=testdb
ha_copy_sync_mode=sync:sync
ha_apply_max_mem_size=500

databases.txt

$CUBRID_DATABASES/databases.txt ($CUBRID_DATABASES 가 설정 안 된 경우 $CUBRID/databases/databases.txt)의 db-host에 마스터 노드와 슬레이브 노드의 호스트 이름을 설정(nodeA:nodeB)한다.

#db-name vol-path db-host log-path lob-base-path
testdb /home/cubrid/DB/testdb nodeA:nodeB /home/cubrid/DB/testdb/log file:/home/cubrid/DB/testdb/lob

CUBRID HA 시작 및 확인¶

CUBRID HA 시작

CUBRID HA 그룹 내의 각 노드에서 cubrid heartbeat start를 수행한다. cubrid heartbeat start 를 가장 먼저 수행한 노드가 마스터 노드가 되므로 유의해야 한다. 이하의 예에서 마스터 노드의 호스트 이름은 nodeA, 슬레이브 노드의 호스트 이름은 nodeB라고 가정한다.

• 마스터 노드

  [nodeA]$ cubrid heartbeat start
  

• 슬레이브 노드

  [nodeB]$ cubrid heartbeat start
  

CUBRID HA 상태 확인

CUBRID HA 그룹 내의 각 노드에서 cubrid heartbeat status를 수행하여 구성 상태를 확인한다.

[nodeA]$ cubrid heartbeat status
@ cubrid heartbeat list
 HA-Node Info (current nodeA-node-name, state master)
   Node nodeB-node-name (priority 2, state slave)
   Node nodeA-node-name (priority 1, state master)
 HA-Process Info (nodeA 9289, state nodeA)
   Applylogdb testdb@localhost:/home1/cubrid1/DB/testdb_nodeB.cub (pid 9423, state registered)
   Copylogdb testdb@nodeB-node-name:/home1/cubrid1/DB/testdb_nodeB.cub (pid 9418, state registered)
   Server testdb (pid 9306, state registered_and_active)

[nodeA]$

CUBRID HA 그룹 내의 각 노드에서 cubrid changemode 유틸리티를 이용하여 서버의 상태를 확인한다.

• 마스터 노드

  [nodeA]$ cubrid changemode testdb@localhost
  The server 'testdb@localhost''s current HA running mode is active.
  

• 슬레이브 노드

  [nodeB]$ cubrid changemode testdb@localhost
  The server 'testdb@localhost''s current HA running mode is standby.
  

CUBRID HA 동작 여부 확인

마스터 노드의 액티브 서버에서 쓰기를 수행한 후 슬레이브 노드의 스탠바이 서버에 정상적으로 반영되었는지 확인한다. HA 환경에서 CSQL 인터프리터로 각 노드에 접속하려면, 데이터베이스 이름 뒤에 접속 대상 호스트 이름을 반드시 지정해야 한다("@<호스트 이름>"). 호스트 이름을 localhost로 지정하면, 로컬 노드에 접속하게 된다.

• 마스터 노드

  [nodeA]$ csql -u dba testdb@localhost -c "create table abc(a int, b int, c int, primary key(a));"
  [nodeA]$ csql -u dba testdb@localhost -c "insert into abc values (1,1,1);"
  [nodeA]$
  

• 슬레이브 노드

  [nodeB]$ csql -u dba testdb@localhost -l -c "select * from abc;"
  === <Result of SELECT Command in Line 1> ===
  <00001> a: 1
          b: 1
          c: 1
  [nodeB]$
  

브로커 설정, 시작 및 확인¶

브로커 설정

데이터베이스 failover 시 정상적인 서비스를 위해서 databases.txt 의 db-host 항목에 데이터베이스의 가용 노드를 설정해야 한다. 그리고 cubrid_broker.conf 의 ACCESS_MODE 를 설정하는데, 이를 생략하면 기본값인 Read Write 모드로 설정된다. 브로커를 별도의 장비로 분리하는 경우 브로커 장비에 cubrid_broker.conf 와 databases.txt 를 반드시 설정해야 한다.

• databases.txt

  #db-name        vol-path                db-host         log-path        lob-base-path
  testdb          /home1/cubrid1/CUBRID/testdb  nodeA:nodeB        /home1/cubrid1/CUBRID/testdb/log file:/home1/cubrid1/CUBRID/testdb/lob
  

• cubrid_broker.conf

  [%testdb_RWbroker]
  SERVICE                 =ON
  BROKER_PORT             =33000
  MIN_NUM_APPL_SERVER     =5
  MAX_NUM_APPL_SERVER     =40
  APPL_SERVER_SHM_ID      =33000
  LOG_DIR                 =log/broker/sql_log
  ERROR_LOG_DIR           =log/broker/error_log
  SQL_LOG                 =ON
  TIME_TO_KILL            =120
  SESSION_TIMEOUT         =300
  KEEP_CONNECTION         =AUTO
  CCI_DEFAULT_AUTOCOMMIT  =ON
  
  # broker mode parameter
  ACCESS_MODE             =RW
  

브로커 시작 및 상태 확인

브로커는 JDBC나 CCI, PHP 등의 응용에서 접근하기 위해 사용하는 것이다. 따라서 간단한 서버 이중화 동작을 시험하고 싶다면 브로커를 시작할 필요 없이 서버 프로세스에 직접 접속하는 CSQL 인터프리터만 실행해서 확인할 수 있다. 브로커는 cubrid broker start 를 실행하여 시작하고 cubrid broker stop 을 실행하여 정지한다.

다음은 브로커를 마스터 노드에서 실행한 예이다.

[nodeA]$ cubrid broker start
@ cubrid broker start
++ cubrid broker start: success
[nodeA]$ cubrid broker status
@ cubrid broker status
% testdb_RWbroker
---------------------------------------------------------
ID   PID   QPS   LQS PSIZE STATUS
---------------------------------------------------------
 1  9532     0     0  48120  IDLE

응용 프로그램 설정

응용 프로그램이 연결할 브로커의 호스트 이름(nodeA_broker, nodeB_broker)과 포트를 연결 URL에 명시한다. 브로커와의 연결 장애가 발생한 경우 다음으로 연결을 시도할 브로커는 altHosts 속성에 명시한다. 아래는 JDBC 프로그램의 예이며, CCI, PHP에 대한 예와 자세한 설명은 CCI 설정, PHP 설정 을 참고한다.

Connection connection = DriverManager.getConnection("jdbc:CUBRID:nodeA_broker:33000:testdb:::?charSet=utf-8&altHosts=nodeB_broker:33000", "dba", "");

cubrid.conf¶

cubrid.conf 파일은 $CUBRID/conf 디렉터리에 위치하며, CUBRID의 전반적인 설정 정보를 담고 있다. 여기에서는 cubrid.conf 중 CUBRID HA가 사용하는 파라미터를 설명한다.

# Service Parameters
[service]
service=server,broker,manager

# Server Parameters
server=testdb
data_buffer_size=512M
log_buffer_size=4M
sort_buffer_size=2M
max_clients=200
cubrid_port_id=1523
db_volume_size=512M
log_volume_size=512M

# HA 구성 시 추가 (Logging parameters)
log_max_archives=100
force_remove_log_archives=no

# HA 구성 시 추가 (HA 모드)
ha_mode=on
log_max_archives=100

cubrid_ha.conf¶

cubrid_ha.conf 파일은 $CUBRID/conf 디렉터리에 위치하며, CUBRID의 HA 기능의 전반적인 설정 정보를 담고 있다. CUBRID HA 기능은 Windows를 지원하지 않고 Linux에서만 사용할 수 있으므로 이 값은 Linux용 CUBRID에서만 의미가 있다.

브로커와 DB 사이의 연결 절차에 대한 자세한 설명은 브로커와 DB 연결을 참고한다.

Time: 04/10/12 17:49:45.030 - ERROR *** file ../../src/connection/tcp.c, line 121 ERROR CODE = -353 Tran = 0, CLIENT = (unknown):(unknown)(-1), EID = 1 Cannot make connection to master server on host "Wrong_HOST_NAME".... Connection timed out

[common]
ha_node_list=cubrid@nodeA:nodeB
ha_db_list=testdb
ha_copy_sync_mode=sync:sync
ha_apply_max_mem_size=500

127.0.0.1 localhost.localdomain localhost
192.168.0.1 nodeA

cubrid_broker.conf¶

cubrid_broker.conf 파일은 $CUBRID/conf 디렉터리에 위치하며, 브로커의 전반적인 설정 정보를 담고 있다. 여기에서는 cubrid_broker.conf 중 CUBRID HA가 사용하는 파라미터를 설명한다.

브로커와 DB 사이의 연결 절차에 대한 자세한 설명은 브로커와 DB 연결을 참고한다.

[%PHRO_broker]
SERVICE                 =ON
BROKER_PORT             =33000
MIN_NUM_APPL_SERVER     =5
MAX_NUM_APPL_SERVER     =40
APPL_SERVER_SHM_ID      =33000
LOG_DIR                 =log/broker/sql_log
ERROR_LOG_DIR           =log/broker/error_log
SQL_LOG                 =ON
TIME_TO_KILL            =120
SESSION_TIMEOUT         =300
KEEP_CONNECTION         =AUTO
CCI_DEFAULT_AUTOCOMMIT  =ON

# Broker mode setting parameter
ACCESS_MODE             =RO
PREFERRED_HOSTS         =localhost

databases.txt¶

databases.txt 파일은 $CUBRID_DATABASES (설정되어 있지 않은 경우 $CUBRID/databases) 디렉터리에 위치하며, db_hosts 값을 설정하여 브로커의 CAS가 접속을 시도하는 서버의 순서를 결정할 수 있다. 여러 노드를 설정하려면 콜론(:)으로 구분한다. cubrid_broker.conf의 CONNECT_ORDER 파라미터 값이 RANDOM이면 무작위한 순서로 접속 순서를 결정한다. 하지만 PREFERRED_HOSTS 파라미터 값이 설정된 경우 명시된 호스트로의 접속을 우선 시도한다.

다음은 databases.txt 설정의 예이다.

#db-name    vol-path        db-host     log-path     lob-base-path
testdb       /home/cubrid/DB/testdb nodeA:nodeB   /home/cubrid/DB/testdb/log  file:/home/cubrid/DB/testdb/lob

JDBC 설정¶

JDBC에서 CUBRID HA 기능을 사용하려면 브로커(nodeA_broker)에 장애가 발생했을 때 다음으로 연결할 브로커(nodeB_broker)의 연결 정보를 연결 URL에 추가로 지정해야 한다. CUBRID HA를 위해 지정되는 속성은 장애가 발생했을 때 연결할 하나 이상의 브로커 노드 정보인 altHosts이다. 이에 대한 자세한 설명은 연결 설정를 참고한다.

다음은 JDBC 설정의 예이다.

Connection connection = DriverManager.getConnection("jdbc:CUBRID:nodeA_broker:33000:testdb:::?charSet=utf-8&altHosts=nodeB_broker:33000", "dba", "");

CCI 설정¶

CCI에서 CUBRID HA 기능을 사용하려면 브로커에 장애가 발생했을 때 연결할 브로커의 연결 정보를 연결 URL에 추가로 지정할 수 있는 cci_connect_with_url() 함수를 사용하여 브로커와 연결해야 한다. CUBRID HA를 위해 지정되는 속성은 장애가 발생했을 때 연결할 하나 이상의 브로커 노드 정보인 altHosts이다.

다음은 CCI 설정의 예이다.

con = cci_connect_with_url ("cci:CUBRID:nodeA_broker:33000:testdb:::?altHosts=nodeB_broker:33000", "dba", NULL);
if (con < 0)
{
      printf ("cannot connect to database\n");
      return 1;
}

PHP 설정¶

PHP에서 CUBRID HA 기능을 사용하려면 브로커에 장애가 발생했을 때 연결할 브로커의 연결 정보를 연결 URL에 추가로 지정할 수 있는 cubrid_connect_with_url 함수를 사용하여 브로커와 연결해야 한다. CUBRID HA를 위해 지정되는 속성은 장애가 발생했을 때 연결할 하나 이상의 브로커 노드 정보인 altHosts이다.

다음은 PHP 설정의 예이다.

<?php
$con = cubrid_connect_with_url ("cci:CUBRID:nodeA_broker:33000:testdb:::?altHosts=nodeB_broker:33000", "dba", NULL);
if ($con < 0)
{
      printf ("cannot connect to database\n");
      return 1;
}
?>

접속 절차¶

브로커가 DB 서버에 접속할 때, 1차 연결을 먼저 시도하고 실패하면 2차 연결을 시도한다.

• 1차 연결: DB 상태(active/standby)와 복제 지연 여부를 확인.
  1. PREFERRED_HOSTS에 명시된 순서로 접속을 시도한다. ACCESS_MODE와 맞지 않는 상태의 DB 또는 복제 지연이 발생하는 DB에는 접속을 거부한다.
  2. CONNECT_ORDER의 값에 따라 databases.txt에 명시된 순서 혹은 무작위로 접속을 시도한다. ACCESS_MODE에 따라 DB 서버의 상태를 확인하며, MAX_NUM_DELAYED_HOSTS_LOOKUP 개수까지 복제 지연 여부도 확인한다.
• 2차 연결: DB 상태(active/standby)와 복제 지연 여부를 무시. 단, SO 브로커는 항상 standby DB에만 접속 허용.
  1. PREFERRED_HOSTS에 명시된 순서로 접속을 시도한다. DB 서버의 상태가 ACCESS_MODE와 맞지 않거나 DB에서 복제 지연이 발생하더라도 접속을 허용한다. 단, SO 브로커는 절대로 active DB에 연결될 수 없다.
  2. CONNECT_ORDER의 값에 따라 databases.txt에 명시된 순서 혹은 무작위로 접속을 시도한다. DB 서버의 상태 및 복제 지연 여부와 무관하게 접속이 가능하면 된다.

파라미터 설정에 따른 동작의 예¶

다음은 파라미터 설정에 따른 동작의 예이다.

호스트 DB 상태

• host1: active
• host2: standby, 복제 지연
• host3: standby, replica, 접속 불가
• host4: standby, replica, 복제 지연
• host5: standby, replica, 복제 지연

호스트 DB의 상태가 위와 같을 때, 설정에 따른 동작의 예는 다음과 같다.

설정에 따른 동작

• 2-1, 2-2, 2-3: 2로부터 (+)는 추가, (#)은 변경.
• 3-1, 3-2, 3-3: 3으로부터 (+)는 추가, (#)은 변경.

cubrid heartbeat 유틸리티¶

cubrid heartbeat 명령은 줄여서 cubrid hb로도 실행할 수 있다.

$ cubrid heartbeat start

$ cubrid heartbeat start testdb

$ cubrid heartbeat stop

$ cubrid heartbeat stop testdb

$ cubrid heartbeat stop -i
or
$cubrid heartbeat stop --immediately

$ cubrid heartbeat copylogdb <start|stop> db_name peer_node

[nodeB]$ cubrid heartbeat copylogdb stop testdb nodeA
[nodeB]$ cubrid heartbeat copylogdb start testdb nodeA

$ cubrid heartbeat applylogdb <start|stop> db_name peer_node

[nodeB]$ cubrid heartbeat applylogdb stop testdb nodeA
[nodeB]$ cubrid heartbeat applylogdb start testdb nodeA

$ cubrid heartbeat reload

$ cubrid heartbeat status
@ cubrid heartbeat status

 HA-Node Info (current nodeB, state slave)
   Node nodeB (priority 2, state slave)
   Node nodeA (priority 1, state master)


 HA-Process Info (master 2143, state slave)
   Applylogdb testdb@localhost:/home/cubrid/DB/testdb_nodeB (pid 2510, state registered)
   Copylogdb testdb@nodeA:/home/cubrid/DB/testdb_nodeA (pid 2505, state registered)
   Server testdb (pid 2393, state registered_and_standby)

cubrid service에 HA 등록¶

CUBRID 서비스에 heartbeat를 등록하면 cubrid service 유틸리티를 사용하여 한 번에 관련된 프로세스들을 모두 구동/정지하거나 상태를 알아볼 수 있어 편리하다. CUBRID 서비스 등록은 cubrid.conf 파일의 [service] 섹션에 있는 service 파라미터에 설정할 수 있다. 이 파라미터에 heartbeat 를 포함하면 cubrid service start / stop 명령을 사용하여 서비스의 프로세스 및 HA 관련 프로세스를 모두 한 번에 구동/중지할 수 있다.

다음은 cubrid.conf 파일을 설정하는 예이다.

# cubrid.conf

...

[service]

...

service=broker,heartbeat

...

[common]

...

ha_mode=on

cubrid applyinfo¶

CUBRID HA의 복제 로그 복사 및 반영 상태를 확인한다.

cubrid applyinfo [options] <database-name>

• database-name : 확인하려는 서버의 데이터베이스 이름을 명시한다. 노드 이름은 입력하지 않는다.

cubrid applyinfo에서 사용하는 [options]는 다음과 같다.

-r, --remote-host-name=HOSTNAME¶

트랜잭션 로그를 복사하는 대상 노드의 호스트 이름을 설정한다. 이 옵션을 설정하면 대상 노드의 액티브 로그 정보(Active Info.)를 출력한다.

-a, --applied-info¶

cubrid applyinfo를 수행한 노드(localhost)의 복제 반영 정보(Applied Info.)를 출력한다. 이 옵션을 사용하기 위해서는 반드시 -L 옵션이 필요하다.

-L, --copied-log-path=PATH¶

상대 노드의 트랜잭션 로그를 복사해 온 위치를 설정한다. 이 옵션이 설정된 경우 상대 노드에서 복사해 온 트랜잭션 로그의 정보(Copied Active Info.)를 출력한다.

-p, --pageid=ID¶

-L 옵션을 설정한 경우 설정 가능하며, 복사해 온 로그의 특정 페이지 정보를 출력한다. 기본값은 0으로, 활성 페이지(active page)를 의미한다.

-v¶

더 자세한 내용을 출력한다.

-i, --interval=SECOND¶

트랜잭션 로그 복사 또는 반영 상태 정보를 지정한 초마다 주기적으로 출력한다. 복제가 지연되는 상태를 확인하려면 이 옵션을 반드시 지정해야 한다

예시

다음은 슬레이브 노드에서 applyinfo 를 실행하여 마스터 노드의 트랜잭션 로그 정보(Active Info.), 슬레이브 노드의 로그 복사 상태 정보(Copied Active Info.)와 로그 반영 상태 정보(Applied Info.)를 확인하는 예이다.

• Applied Info. : 슬레이브 노드가 복제 로그를 반영한 상태 정보를 나타낸다.
• Copied Active Info. : 슬레이브 노드가 복제 로그를 복사한 상태 정보를 나타낸다.
• Active Info. : 마스터 노드가 트랜잭션 로그를 기록한 상태 정보를 나타낸다.
• Delay in Copying Active Log: 트랜잭션 로그 복사 지연 상태를 나타낸다.
• Delay in Applying Copied Log: 트랜잭션 로그 반영 지연 상태를 나타낸다.

[nodeB] $ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a -i 3 testdb

 *** Applied Info. ***
Insert count                   : 289492
Update count                   : 71192
Delete count                   : 280312
Schema count                   : 20
Commit count                   : 124917
Fail count                     : 0

 *** Copied Active Info. ***
DB name                        : testdb
DB creation time               : 04:29:00.000 PM 11/04/2012 (1352014140)
EOF LSA                        : 27722 | 10088
Append LSA                     : 27722 | 10088
HA server state                : active

 ***  Active Info. ***
DB name                        : testdb
DB creation time               : 04:29:00.000 PM 11/04/2012 (1352014140)
EOF LSA                        : 27726 | 2512
Append LSA                     : 27726 | 2512
HA server state                : active

 *** Delay in Copying Active Log ***
Delayed log page count         : 4
Estimated Delay                : 0 second(s)

 *** Delay in Applying Copied Log ***
Delayed log page count         : 1459
Estimated Delay                : 22 second(s)

각 상태 정보가 나타내는 항목을 살펴보면 다음과 같다.

• Applied Info.
  • Committed page : 복제 로그 반영 프로세스에 의해 마지막으로 반영된 트랜잭션의 커밋된 pageid와 offset 정보. 이 값과 "Copied Active Info."의 EOF LSA 값의 차이만큼 복제 반영의 지연이 있다.
  • Insert Count : 복제 로그 반영 프로세스가 반영한 Insert 쿼리의 개수
  • Update Count : 복제 로그 반영 프로세스가 반영한 Update 쿼리의 개수
  • Delete Count : 복제 로그 반영 프로세스가 반영한 Delete 쿼리의 개수
  • Schema Count : 복제 로그 반영 프로세스가 반영한 DDL 문의 개수
  • Commit Count : 복제 로그 반영 프로세스가 반영한 트랜잭션의 개수
  • Fail Count : 복제 로그 반영 프로세스가 반영에 실패한 DML 및 DDL 문의 개수
• Copied Active Info.
  • DB name : 복제 로그 복사 프로세스가 로그를 복사하는 대상 데이터베이스의 이름
  • DB creation time : 복제 로그 복사 프로세스가 복사하는 데이터베이스의 생성 시간
  • EOF LSA : 복제 로그 복사 프로세스가 대상 노드에서 복사한 로그의 마지막 pageid와 offset 정보. 이 값과 "Active Info."의 EOF LSA 값의 차이 및 "Copied Active Info."의 Append LSA 값의 차이만큼 로그 복사의 지연이 있다.
  • Append LSA : 복제 로그 복사 프로세스가 디스크에 실제로 쓴 로그의 마지막 pageid와 offset 정보. 이는 EOF LSA보다 작거나 같을 수 있다. 이 값과 "Copied Active Info"의 EOF LSA 값의 차이만큼 로그 복사의 지연이 있다.
  • HA server state : 복제 로그 복사 프로세스가 로그를 받아오는 데이터베이스 서버 프로세스의 상태. 상태에 대한 자세한 설명은 서버 를 참고하도록 한다.
• Active Info.
  • DB name : -r 옵션에 설정한 노드의 데이터베이스의 이름
  • DB creation time : -r 옵션에 설정한 노드의 데이터베이스 생성 시간
  • EOF LSA : -r 옵션에 설정한 노드의 데이터베이스 트랜잭션 로그의 마지막 pageid와 offset 정보. 이 값과 "Copied Active Info."의 EOF LSA 값의 차이만큼 복제 로그 복사의 지연이 있다.
  • Append LSA : -r 옵션에 설정한 노드의 데이터베이스 서버가 디스크에 실제로 쓴 트랜잭션 로그의 마지막 pageid와 offset 정보
  • HA server state : -r 옵션에 설정한 노드의 데이터베이스 서버 상태
• Delay in Copying Active Log
  • Delayed log page count: 복사가 지연된 트랜잭션 로그 페이지 개수
  • Estimated Delay: 트랜잭션 로그 복사 예상 완료 시간
• Delay in Applying Copied Log
  • Delayed log page count: 반영이 지연된 트랜잭션 로그 페이지 개수
  • Estimated Delay: 트랜잭션 로그 반영 예상 완료 시간

레플리카 노드에서 해당 명령을 실행할 때 cubrid_ha.conf에 "ha_replica_delay=30s"가 설정되어 있으면 다음의 정보가 추가로 출력된다.

 *** Replica-specific Info. ***
Deliberate lag                 : 30 second(s)
Last applied log record time   : 2013-06-20 11:20:10

각 상태 정보가 나타내는 항목을 살펴보면 다음과 같다.

• Replica-specific Info.
  • Deliberate lag: ha_replica_delay 파라미터에 의해 사용자가 설정한 지연 시간
  • Last applied log record time: 레플리카 노드에서 최근 반영된 복제 로그가 마스터 노드에서 실제로 반영되었던 시간

레플리카 노드에서 해당 명령을 실행할 때 cubrid_ha.conf에 "ha_replica_delay=30s", "ha_replica_time_bound=2013-06-20 11:31:00"이 설정되어 있으면 ha_replica_delay 설정은 무시되며 다음의 정보가 추가로 출력된다.

 *** Replica-specific Info. ***
Last applied log record time   : 2013-06-20 11:25:17
Will apply log records up to   : 2013-06-20 11:31:00

각 상태 정보가 나타내는 항목을 살펴보면 다음과 같다.

• Replica-specific Info.
  • Last applied log record time: 레플리카 노드에서 최근 반영한 복제 로그가 마스터 노드에서 반영된 시간
  • Will apply log records up to: 해당 시간까지 마스터 노드에서 반영된 복제 로그를 레플리카 노드에 반영

ha_replica_time_bound 시간이 되어 applylogdb가 복제 반영을 완전히 멈춘 경우 $CUBRID/log/db-name@local-node-name_applylogdb_db-name_remote-node-name.err 에 출력되는 에러 메시지는 다음과 같다.

Time: 06/20/13 11:51:05.549 - ERROR *** file ../../src/transaction/log_applier.c, line 7913 ERROR CODE = -1040 Tran = 1, EID = 3
HA generic: applylogdb paused since it reached a log record committed on master at 2013-06-20 11:31:00 or later.
Adjust or remove ha_replica_time_bound and restart applylogdb to resume.

cubrid changemode¶

CUBRID HA의 서버 상태를 확인하고 변경한다.

cubrid changemode [options] <database-name@node-name>

• database-name@node-name: 확인 또는 변경하고자 하는 서버의 이름을 명시하고 @으로 구분하여 노드 이름을 명시한다. [options]를 생략하면 확인하고자 하는 서버 상태가 출력된다.

cubrid changemode에서 사용하는 [options]는 다음과 같다.

-m, --mode=MODE¶

서버 상태를 변경한다.

옵션 값으로 standby, maintenance, active 중 하나를 입력할 수 있다.

• 서버의 상태가 standby이면 maintenance로 변경할 수 있다.
• 서버의 상태가 maintenance이면 standby로 변경할 수 있다.
• 서버의 상태가 to-be-active**이면 **active로 변경할 수 있다. 단, --force 옵션과 함께 사용해야 한다. 아래 --force 옵션의 설명을 참고한다.

-f, --force¶

서버의 상태를 강제로 변경할지 여부를 설정한다.

현재 서버가 to-be-active 상태일 때 active 상태로 강제 변경하려고 하는 경우에는 반드시 사용하며, 이를 설정하지 않으면 active 상태로 변경되지 않는다. 강제 변경 시 복제 노드 간 데이터 불일치가 발생할 수 있으므로 사용하지 않는 것을 권장한다.

-t, --timeout=SECOND¶

기본값 5(초). 노드 상태를 standby에서 maintenance로 변경할 때 진행 중이던 트랜잭션이 정상 종료되기까지 대기하는 시간을 설정한다.

설정한 시간이 지나도 트랜잭션이 진행 중이면 강제 종료 후 maintenance 상태로 변경하고, 설정한 시간 이내에 모든 트랜잭션이 정상 종료되면 즉시 maintenance 상태로 변경한다.

상태 변경 가능 표

다음은 현재 상태에 따라 변경할 수 있는 상태를 표시한 표이다.

* 서버가 to-be-active 상태일 때 active 상태로 강제 변경하면 복제 노드 간 불일치가 발생할 수 있으므로 관련 내용을 충분히 숙지한 사용자가 아니라면 사용하지 않는 것을 권장한다.

예시

다음 예는 localhost 노드의 testdb 서버 상태를 maintenance 상태로 변경한다. 이때 진행 중이던 모든 트랜잭션이 정상 종료하기까지 대기하는 시간은 -t 옵션의 기본값인 5초이다. 이 시간 이내에 모든 트랜잭션이 종료되면 즉시 상태를 변경하며, 이 시간이 지나도 진행 중인 트랜잭션이 존재하면 이를 롤백한 후 상태를 변경한다.

$ cubrid changemode -m maintenance testdb@localhost
The server 'testdb@localhost''s current HA running mode is maintenance.

다음 예는 localhost 노드의 testdb 서버의 상태를 조회한다.

$ cubrid changemode testdb@localhost
The server 'testdb@localhost''s current HA running mode is active.

CUBRID 매니저 HA 모니터링¶

CUBRID 매니저는 CUBRID 데이터베이스 관리 및 질의 기능을 GUI 환경에서 제공하는 CUBRID 데이터베이스 전용 관리 도구이다. CUBRID 매니저는 CUBRID HA 그룹에 대한 관계도와 서버 상태를 확인할 수 있는 HA 대시보드를 제공한다. 자세한 설명은 cubrid 매니저 매뉴얼 을 참고한다.

HA 기본 구성¶

CUBRID HA의 가장 기본적인 구성으로, 하나의 마스터 노드와 하나의 슬레이브 노드로 구성된다.

CUBRID HA 고유의 기능인 장애 시 무중단(nonstop) 서비스 기능에 초점을 맞춘 구성으로, 작은 서비스에서 적은 리소스를 투입하여 구성할 수 있다. HA 기본 구성은 하나의 마스터 노드와 하나의 슬레이브 노드로 서비스를 제공하므로, 읽기 부하를 분산하려면 다중 슬레이브 노드 구성 또는 부하 분산 구성이 좋다. 또한, 슬레이브 노드 또는 레플리카 노드 등의 특정 노드에 읽기 전용으로 접속하려면 Read Only 브로커 또는 Preferred Host Read Only 브로커를 구성한다. 브로커 구성에 대한 설명은 브로커 이중화 를 참고한다.

노드 설정 예시

HA 기본 구성의 각 노드는 다음과 같이 설정한다.

• node A (마스터 노드)

  • cubrid.conf 파일의 ha_mode 를 on 으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=59901
    ha_node_list=cubrid@nodeA:nodeB
    ha_db_list=testdb
    

• node B (슬레이브 노드) : node A 와 동일하게 설정한다.

브로커 노드의 databases.txt 파일에는 db-host 에 HA로 구성된 호스트의 목록을 우선순위에 따라 순서대로 설정해야 한다. 다음은 databases.txt 파일의 예이다.

#db-name    vol-path                  db-host       log-path       lob-base-path
testdb     /home/cubrid/DB/testdb     nodeA:nodeB   /home/cubrid/DB/testdb/log file:/home/cubrid/DB/testdb/lob

cubrid_broker.conf 파일은 브로커를 어떻게 구성하느냐에 따라 다양하게 설정할 수 있으며 databases.txt 파일과 함께 별도의 장비로 구성하여 설정할 수도 있다.

다음 예는 각 노드에 RW 브로커를 설정한 경우이며 node A, node B 둘 다 같은 값으로 구성한다.

[%RW_broker]
...

# Broker mode setting parameter
    ACCESS_MODE             =RW

응용 프로그램 연결 설정

환경 설정의 JDBC 설정, CCI 설정, PHP 설정 을 참고한다.

참고

이와 같은 구성에서 트랜잭션 로그의 이동 경로를 중심으로 살펴보면 다음과 같다.

다중 슬레이브 노드 구성¶

다중 슬레이브 노드 구성은 한 개의 마스터 노드와 여러 개의 슬레이브 노드를 두어 CUBRID의 서비스 가용성을 높인 구성이다.

CUBRID HA 그룹 내의 모든 노드에서 복제 로그 복사 프로세스와 복제 로그 반영 프로세스가 구동되므로 복제 로그를 복사하는 부하가 생긴다. 따라서 CUBRID HA 그룹 내의 모든 노드는 네트워크 및 디스크 사용률이 높다.

HA로 구성된 노드 수가 많으므로 CUBRID HA 그룹 내의 여러 노드에 장애가 발생해도 하나의 노드만 있으면 읽기 쓰기 서비스를 제공할 수 있다.

다중 슬레이브 노드 구성에서 failover가 일어날 때 마스터 노드가 될 노드는 ha_node_list 에 정의한 순서에 따라 지정된다. 만약 ha_node_list 값이 nodeA:nodeB:nodeC이고 마스터 노드가 node A 이면, 마스터 노드에 장애가 발생했을 때 node B 가 마스터 노드가 된다.

노드 설정 예시

다중 슬레이브 구성의 각 노드는 다음과 같이 설정한다.

• node A (마스터 노드)

  • cubrid.conf 파일의 ha_mode 를 on 으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=59901
    ha_node_list=cubrid@nodeA:nodeB:nodeC
    ha_db_list=testdb
    ha_copy_sync_mode=sync:sync:sync
    

• node B, node C (슬레이브 노드): node A 와 동일하게 설정한다.

브로커 노드의 databases.txt 파일에는 db-host 에 HA 구성된 호스트의 목록을 우선순위에 따라 순서대로 설정해야 한다. 다음은 databases.txt 파일의 예이다.

#db-name    vol-path                  db-host             log-path       lob-base-path
testdb     /home/cubrid/DB/testdb     nodeA:nodeB:nodeC   /home/cubrid/DB/testdb/log file:/home/cubrid/DB/testdb/lob

cubrid_broker.conf 파일은 브로커를 어떻게 구성하느냐에 따라 다양하게 설정할 수 있으며 databases.txt 파일과 함께 별도의 장비로 구성하여 설정할 수도 있다. 예시에서는 node A, node B, node C에 RW 브로커를 설정하였다.

다음은 node A, node B, node C 의 cubrid_broker.conf 의 예이다.

[%RW_broker]
...

# Broker mode setting parameter
ACCESS_MODE             =RW

응용 프로그램 연결 설정

node A, node B 또는 node C 에 있는 브로커 중 하나와 연결한다.

Connection connection = DriverManager.getConnection(
    "jdbc:CUBRID:nodeA:33000:testdb:::?charSet=utf-8&altHosts=nodeB:33000,nodeC:33000", "dba", "");

기타 자세한 사항은 환경 설정의 JDBC 설정, CCI 설정, PHP 설정 을 참고한다.

참고

이와 같은 구성에서 트랜잭션 로그의 이동 경로를 중심으로 살펴보면 다음과 같다.

부하 분산 구성¶

부하 분산 구성은 HA 구성(한 개의 마스터 노드와 한 개의 슬레이브 노드)에 여러 개의 레플리카 노드를 두어 CUBRID 서비스의 가용성을 높이고, 많은 읽기 부하를 분산하여 처리할 수 있는 구성이다.

레플리카 노드들은 HA 구성에 포함된 노드들로부터 복제 로그를 받아 데이터를 동일하게 유지하고, HA 구성에 포함된 노드들은 레플리카 노드에서 복제 로그를 받지 않으므로 다중 슬레이브 구성에 비해 네트워크 및 디스크 사용률이 낮다.

레플리카 노드는 HA 구성에 포함되지 않으므로 HA 구성 내의 모든 노드에 장애가 발생해도 failover되지 않고 읽기 서비스만 제공한다.

노드 설정 예시

부하 분산 구성의 각 노드는 다음과 같이 설정한다.

• node A (마스터 노드)

  • cubrid.conf 파일의 ha_mode를 on으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=12345
    ha_node_list=cubrid@nodeA:nodeB
    ha_replica_list=cubrid@nodeC:nodeD:nodeE
    ha_db_list=testdb
    ha_copy_sync_mode=sync:sync
    

• node B (슬레이브 노드): node A와 동일하게 설정한다.

• node C, node D, node E (레플리카 노드)

  • cubrid.conf 파일의 ha_mode를 replica로 설정한다.

    ha_mode=replica
    

  • cubrid_ha.conf 파일은 node A와 동일하게 설정한다.

cubrid_broker.conf 파일은 브로커를 어떻게 구성하느냐에 따라 다양하게 설정할 수 있으며 databases.txt 파일과 함께 별도의 장비로 구성하여 설정할 수도 있다.

예시에서는 브로커와 DB 서버를 같은 장비에 구성했으며, node A, node B에 RW 브로커를 설정하고, node C, node D, node E에 "CONNECT_ORDER=RANDOM"과 "PREFERRED_HOSTS=localhost"를 포함하는 SO 브로커를 설정하였다. node C, node D, node E는 "PREFERRED_HOSTS=localhost"이기 때문에 로컬 DB 서버에 우선 접속을 시도하며, "CONNECT_ORDER=RANDOM"이므로 localhost 접속에 실패할 경우 databases.txt의 db-host에 명시된 호스트들 중 하나에 랜덤하게 접속을 시도한다.

다음은 node A와 node B의 cubrid_broker.conf 예이다.

[%RW_broker]
...

# Broker mode setting parameter
ACCESS_MODE             =RW

다음은 node C, node D, node E의 cubrid_broker.conf 예이다.

[%PHRO_broker]
...

# Broker mode setting parameter
ACCESS_MODE             =SO
PREFERRED_HOSTS         =localhost

브로커 노드의 databases.txt 파일에는 브로커의 용도에 맞게 HA 또는 부하 분산 서버와 연결될 수 있도록 DB 서버 호스트의 목록을 순서대로 설정해야 한다.

다음은 node A와 node B의 databases.txt 파일의 예이다.

#db-name    vol-path                  db-host       log-path                   lob-base-path
testdb      /home/cubrid/DB/testdb   nodeA:nodeB   /home/cubrid/DB/testdb/log  file:/home/cubrid/CUBRID/testdb/lob

다음은 node C, node D, node E의 databases.txt 파일의 예이다.

#db-name    vol-path                db-host             log-path                    lob-base-path
testdb     /home/cubrid/DB/testdb   nodeC:nodeD:nodeE   /home/cubrid/DB/testdb/log  file:/home/cubrid/CUBRID/testdb/lob

응용 프로그램 연결 설정

읽기 쓰기로 접속하기 위한 응용 프로그램은 node A 또는 node B에 있는 브로커에 연결한다. 다음은 JDBC 응용 프로그램의 예이다.

Connection connection = DriverManager.getConnection(
    "jdbc:CUBRID:nodeA:33000:testdb:::?charSet=utf-8&altHosts=nodeB:33000", "dba", "");

읽기 전용으로 접속하기 위한 응용 프로그램은 node C, node D 또는 node E에 있는 브로커에 연결한다. 다음은 JDBC 응용 프로그램의 예이다. "loadBalance=true"로 설정하여 메인 호스트와 altHosts에 지정한 호스트들에 랜덤한 순서로 연결한다.

Connection connection = DriverManager.getConnection(
    "jdbc:CUBRID:nodeC:33000:testdb:::?charSet=utf-8&loadBalance=true&altHosts=nodeD:33000,nodeE:33000", "dba", "");

기타 자세한 사항은 환경 설정의 JDBC 설정, CCI 설정, PHP 설정을 참고한다.

참고

이와 같은 구성에서 트랜잭션 로그의 이동 경로를 중심으로 살펴보면 다음과 같다.

다중 스탠바이 서버 구성¶

한 개의 마스터 노드와 한 개의 슬레이브 노드로 구성되나, 여러 서비스의 슬레이브 노드를 하나의 물리적인 서버에 구성한다.

매우 작은 서비스에서 슬레이브 노드로 읽기 부하를 받지 않아도 되는 경우를 위한 것으로, CUBRID 서비스의 가용성만을 위한 구성이다. 따라서 failover 후 장애가 발생했던 마스터 노드가 복구되면 부하를 다시 마스터 노드로 옮겨 오도록 하여 슬레이브 노드들이 들어있는 서버의 부하를 최소화해야 한다.

노드 설정 예시

HA 기본 구성의 각 노드는 다음과 같이 설정한다.

• node AM, node AS : 두 노드는 동일하게 설정한다.

  • cubrid.conf 파일의 ha_mode를 on으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=10000
    ha_node_list=cubridA@Host1:Host5
    ha_db_list=testdbA1,testdbA2
    ha_copy_sync_mode=sync:sync
    

• node BM, node BS : 두 노드는 동일하게 설정한다.

  • cubrid.conf 파일의 ha_mode를 on으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=10001
    ha_node_list=cubridB@Host2:Host5
    ha_db_list=testdbB1,testdbB2
    ha_copy_sync_mode=sync:sync
    

• node CM, node CS : 두 노드는 동일하게 설정한다.

  • cubrid.conf 파일의 ha_mode를 on으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=10002
    ha_node_list=cubridC@Host3:Host5
    ha_db_list=testdbC1,testdbC2
    ha_copy_sync_mode=sync:sync
    

• node DM, node DS : 두 노드는 동일하게 설정한다.

  • cubrid.conf 파일의 ha_mode를 on으로 설정한다.

    ha_mode=on
    

  • 다음은 cubrid_ha.conf 파일의 설정 예이다.

    ha_port_id=10003
    ha_node_list=cubridD@Host4:Host5
    ha_db_list=testdbD1,testdbD2
    ha_copy_sync_mode=sync:sync
    

읽기 쓰기 서비스 중 운영 시나리오¶

이 운영 시나리오는 서비스의 읽기 쓰기에 영향을 받지 않으므로, CUBRID 운영으로 인해 서비스에 미치는 영향이 매우 작다. 읽기 쓰기 서비스 중의 운영 시나리오는 failover가 일어나는 경우와 그렇지 않은 경우로 나눌 수 있다.

failover가 필요 없는 운영 시나리오

다음 작업은 CUBRID HA 그룹 내의 노드를 종료하고 다시 구동하지 않고 바로 수행할 수 있다.

failover가 필요한 운영 시나리오

다음 작업은 CUBRID HA 그룹 내의 노드를 종료하고 운영 작업을 완료한 후 구동해야 한다.

읽기 서비스 중 운영 시나리오¶

이 운영 시나리오는 읽기 서비스만 가능하도록 하여 운영 작업을 수행한다. 서비스의 읽기 서비스만을 허용하거나 브로커의 모드 설정을 Read Only로 동적 변경해야 한다. 읽기 서비스 중의 운영 시나리오는 failover가 일어나는 경우와 그렇지 않은 경우로 나눌 수 있다.

failover가 필요 없는 운영 시나리오

다음 작업은 CUBRID HA 그룹 내의 노드를 종료하고 다시 구동하지 않고 바로 수행할 수 있다.

failover가 필요한 운영 시나리오

다음 작업은 CUBRID HA 그룹 내의 노드를 종료하고 운영 작업을 완료한 후 구동해야 한다.

서비스 정지 후 운영 시나리오¶

이 운영 시나리오는 CUBRID HA 그룹 내의 모든 노드들을 정지 후 운영 작업을 수행해야 한다.

레플리카 복제 지연 설정 시나리오¶

이 운영 시나리오는 마스터 노드에서 실수로 데이터를 삭제한 경우를 감지하여 특정 시점 이전으로 데이터를 되돌리고 싶을 때, 레플리카 노드를 통해 긴급히 이전 데이터까지 복구할 수 있게 하기 위해 지정한 시간 간격을 두고 복제를 진행하며 특정 시점에서 복제를 정지하도록 복제 정지 시간을 설정한다.

서비스 정지 후 슬레이브 추가¶

마스터 노드 한 대로만 운영하는 도중 서비스를 정지한 후 슬레이브를 추가하여 마스터와 슬레이브를 1:1로 구성하는 경우를 알아보자.

• nodeA: 마스터 노드 호스트 명
• nodeB: 새로 추가할 슬레이브 노드 호스트 명

이 시나리오에서 데이터베이스는 다음 명령으로 이미 생성되어 있다고 가정한다. createdb 수행 시 로캘 이름과 문자셋은 마스터 노드와 슬레이브 노드가 서로 동일해야 한다.

export CUBRID_DATABASES=/home/cubrid/DB
mkdir $CUBRID_DATABASES/testdb
mkdir $CUBRID_DATABASES/testdb/log
cd $CUBRID_DATABASES/testdb
cubrid createdb testdb -L $CUBRID_DATABASES/testdb/log en_US.utf8

백업 파일의 저장 위치를 별도의 옵션으로 지정하지 않으면 $CUBRID_DATABASES/testdb 디렉터리가 기본이 된다.

브로커 노드가 별도의 장비에 구성되어 있고 브로커를 추가하지 않는 경우, 응용 프로그램에서 URL의 변경을 필요로 하지 않는다.

이 시나리오에서는 브로커 노드를 별도의 장비로 분리하지 않은 것으로 가정한다.

이상을 염두에 두고 다음의 순서로 작업한다.

0. 마스터 노드와 슬레이브 노드의 HA 설정

   • 마스터 노드와 슬레이브 노드가 동일하게 $CUBRID/conf/cubrid.conf 설정

     [service]
     service=server,broker,manager
     
     # 서비스 시작 시 구동될 데이터베이스 이름 추가
     server=testdb
     
     [common]
     ...
     
     # HA 구성 시 추가 (Logging parameters)
     force_remove_log_archives=no
     
     # HA 구성 시 추가 (HA 모드)
     ha_mode=on
     

   • 마스터 노드와 슬레이브 노드가 동일하게 $CUBRID/conf/cubrid_ha.conf 설정

     [common]
     ha_port_id=59901
     
     # cubrid는 HA 시스템의 그룹 이름이고, nodeA와 nodeB는 호스트 이름임.
     ha_node_list=cubrid@nodeA:nodeB
     
     ha_db_list=testdb
     ha_copy_sync_mode=sync:sync
     ha_apply_max_mem_size=500
     

   • 마스터 노드와 슬레이브 노드가 동일하게 $CUBRID_DATABASES/databases.txt 설정.

     #db-name    vol-path                db-host         log-path                    lob-base-path
     testdb      /home/cubrid/DB/testdb  nodeA:nodeB     /home/cubrid/DB/testdb/log  file:/home/cubrid/DB/testdb/lob
     

   • HA 환경에서 브로커, 응용 프로그램 설정

     브로커 설정과 응용 프로그램에서 URL에 altHosts를 추가하는 것에 대한 설명은 cubrid_broker.conf를 참고한다.

   • 마스터 노드와 동일하게 슬레이브 노드의 로캘 라이브러리 설정

     [nodeA]$ scp $CUBRID/conf/cubrid_locales.txt cubrid_usr@nodeB:$CUBRID/conf/.
     [nodeB]$ make_locale.sh -t64
     

   • 슬레이브 노드에 데이터베이스 디렉터리 생성

     [nodeB]$ cd $CUBRID_DATABASES
     [nodeB]$ mkdir testdb
     

   • 슬레이브 노드에 로그 디렉터리 생성(마스터 노드와 같은 위치에 생성)

     [nodeB]$ cd $CUBRID_DATABASES/testdb
     [nodeB]$ mkdir log
     

1. 마스터 노드 서비스 중지, 마스터 데이터베이스 백업

   [nodeA]$ cubrid service stop
   

   마스터 노드의 데이터베이스를 백업하고, 슬레이브 노드에 백업 파일을 복사한다.

   마스터 노드에서 백업 파일의 저장 위치는 별도의 지정이 없으면 testdb 의 로그 디렉터리가 되며, 슬레이브 노드에도 마스터 노드와 같은 위치에 백업 파일을 복사한다. 아래에서 testdb_bk0v000은 백업 볼륨 파일, testdb_bkvinf는 백업 볼륨 정보 파일이다.

   [nodeA]$ cubrid backupdb -z -S testdb
   Backup Volume Label: Level: 0, Unit: 0, Database testdb, Backup Time: Thu Apr 19 16:05:18 2012
   [nodeA]$ cd $CUBRID_DATABASES/testdb/log
   [nodeA]$ scp testdb_bk* cubrid_usr@nodeB:$CUBRID_DATABASES/testdb/log
   cubrid_usr@nodeB's password:
   testdb_bk0v000                            100% 6157KB   6.0MB/s   00:00
   testdb_bkvinf                             100%   66     0.1KB/s   00:00
   

2. 슬레이브 노드에서 데이터베이스 복구.

   이때, 마스터 노드와 슬레이브 노드의 볼륨 경로가 반드시 같아야 한다.

   [nodeB]$ cubrid restoredb -B $CUBRID_DATABASES/testdb/log testdb
   

3. 마스터 노드 시작, 슬레이브 노드 시작

   [nodeA]$ cubrid heartbeat start
   

   마스터 노드가 정상 구동되었음을 확인한 후, 슬레이브 노드를 시작한다.

   제일 아래에서 nodeA의 state가 registered_and_to_be_active에서 registered_and_active로 변경되면 마스터 노드가 정상 구동된 것이다.

   [nodeA]$ cubrid heartbeat status
   @ cubrid heartbeat status
   
    HA-Node Info (current nodeA, state master)
      Node nodeB (priority 2, state unknown)
      Node nodeA (priority 1, state master)
   
    HA-Process Info (master 123, state master)
   
      Applylogdb testdb@localhost:/home/cubrid/DB/testdb_nodeB (pid 234, state registered)
      Copylogdb testdb@nodeB:/home/cubrid/DB/testdb_nodeB (pid 345, state registered)
      Server testdb (pid 456, state registered_and_to_be_active)
   
   [nodeB]$ cubrid heartbeat start
   

   마스터 노드, 슬레이브 노드의 HA 구성이 정상 동작하는지 확인한다.

   [nodeA]$ csql -u dba testdb@localhost -c"create table tbl(i int primary key);insert into tbl values (1),(2),(3)"
   
   [nodeB]$ csql -u dba testdb@localhost -c"select * from tbl"
   
               i
   =============
               1
               2
               3
   

서비스 운영 중 슬레이브 하나 더 추가¶

다음은 마스터:슬레이브로 HA 서비스 운영 중에 기존 슬레이브로부터 새 슬레이브를 추가하는 시나리오이다. "마스터:슬레이브"는 1:1에서 1:2가 된다.

• nodeA: 마스터 노드 호스트 명
• nodeB: 슬레이브 노드 호스트 명
• nodeC: 새로 추가할 슬레이브 노드 호스트 명

HA 서비스 운영 중 슬레이브를 새로 추가하려면 기존의 마스터 또는 슬레이브를 이용할 수 있는데, 보통 마스터에 비해 슬레이브가 상대적으로 디스크 I/O 부하가 적다고 보고, 여기에서는 기존 슬레이브를 이용하여 추가로 슬레이브를 구성해보자.

export CUBRID_DATABASES=/home/cubrid/DB
mkdir $CUBRID_DATABASES/testdb
mkdir $CUBRID_DATABASES/testdb/log
cd $CUBRID_DATABASES/testdb
cubrid createdb testdb -L $CUBRID_DATABASES/testdb/log en_US.utf8

0. nodeC의 HA 설정

   • nodeC는 nodeB와 동일하게 $CUBRID/conf/cubrid.conf 설정

     HA 모드로 구동 중 복제되지 않은 로그가 삭제되지 않도록 하기 위해 반드시 "force_remove_log_archives=no"로 설정한다.

     [service]
     service=server,broker,manager
     
     [common]
     ...
     
     # HA 구성 시 추가 (Logging parameters)
     force_remove_log_archives=no
     
     # HA 구성 시 추가 (HA 모드)
     ha_mode=on
     

   • nodeC는 nodeB와 동일하게 $CUBRID/conf/cubrid_ha.conf 설정

     단, ha_node_list에 nodeC를 추가하고, ha_copy_sync_mode에 sync를 하나 더 추가한다.

     [common]
     ha_port_id=59901
     
     # cubrid는 HA 시스템의 그룹 이름이고, nodeA, nodeB, nodeC는 호스트 이름임.
     ha_node_list=cubrid@nodeA:nodeB:nodeC
     
     ha_db_list=testdb
     ha_copy_sync_mode=sync:sync:sync
     ha_apply_max_mem_size=500
     

   • nodeA, nodeB와 동일하게 nodeC의 로캘 라이브러리 설정

     [nodeB]$ scp $CUBRID/conf/cubrid_locales.txt cubrid_usr@nodeC:$CUBRID/conf/.
     [nodeC]$ make_locale.sh -t64
     

   • nodeC의 $CUBRID_DATABASES/databases.txt에서 db-host에 nodeA, nodeB, nodeC 추가

     #db-name     vol-path                   db-host             log-path                        lob-base-path
     testdb       /home/cubrid/DB/testdb     nodeA:nodeB:nodeC   /home/cubrid/DB/testdb/log      file:/home/cubrid/DB/testdb/lob
     

     databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다. 예를 들어, db-host에 nodeA:nodeB만 쓰거나, localhost만 써도 된다. 다만, 로컬에서 접속하는 경우(csql -u dba testdb@localhost)를 감안하여 db-host에 localhost 또는 로컬 호스트의 이름은 반드시 포함한다.

1. 백업 이후 복구 도중 nodeB의 복제 로그 삭제 방지를 위한 설정 적용

   nodeB에서 백업한 이후 nodeC에 복구하는 도중에도 서비스가 계속된다면 nodeB의 복제 로그가 추가될 수 있는데, 설정에 따라 슬레이브의 복제 로그가 nodeC에 복제되기도 전에 삭제될 수 있다. 이를 방지하기 위해 다음과 같은 설정을 한다.

   • nodeB에 DB 재구동 없이 ha_copy_log_max_archives 값을 크게 변경

     nodeB에서 백업을 받은 시점부터, nodeC가 구동한 이후 데이터가 마스터와 동일해질 때까지 수행된 트랜잭션이 보관되어야, 백업 시점 이후의 트랜잭션을 nodeC에 반영할 수 있다.

     따라서, 백업 이후 추가된 nodeB의 복제 로그는 유지되어야 한다.

     여기서는 nodeC 구축 시간 동안 수행되는 트랜잭션을 충분히 보관할 수 있는 복제 로그 개수를 5라고 가정한다.

     $CUBRID/conf/cubrid_ha.conf 편집

     ha_copy_log_max_archives=5
     

     nodeB의 applylogdb 프로세스에 ha_copy_log_max_archives 파라미터 변경 내역 반영

     [nodeB]$ cubrid heartbeat applylogdb stop testdb nodeA
     [nodeB]$ cubrid heartbeat applylogdb start testdb nodeA
     

     Note

     마스터 노드인 nodeA만 사용하여 nodeC를 구축한다면 nodeB에서 복제 로그를 복사하는 작업은 불필요하므로, nodeB에서 ha_copy_log_max_archives를 변경하는 작업 역시 불필요하다.

     대신 nodeA에 변경된 log_max_archives를 적용해야 한다.

     cubrid.conf의 log_max_archives 파라미터는 "SET SYSTEM PARAMETERS" 구문만으로 서비스 중 변경이 가능하다.

     [nodeA]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=5'" testdb@localhost
     

2. nodeB에서 백업, nodeC에 복구

   • nodeB 백업

     [nodeB]$ cd $CUBRID_DATABASES/testdb/log
     [nodeB]$ cubrid backupdb --sleep-msecs=10 -C -o output.txt testdb@localhost
     

     Note

     --sleep-msecs는 1MB의 백업 파일이 쓰여질 때마다 쉬는 시간을 설정하는 옵션으로, 단위는 밀리초이다. 백업할 장비의 디스크 I/O 부하가 심한 경우 이 값을 설정하는 것을 고려하되, 이 값이 클수록 백업 시간이 길어지므로 가급적이면 부하가 적은 시간대에 백업하고 이 값은 작게 설정할 것을 권장한다.

     nodeB의 부하가 전혀 없는 상태라면 이 옵션을 생략해도 무방하다.

     -o 옵션으로 명시한 파일에는 백업 결과 정보가 기록된다.

   • 백업 파일을 nodeC에 복사

     [nodeB]$
     [nodeB]$ scp -l 131072 testdb_bk* cubrid_usr@nodeC:$CUBRID_DATABASES/testdb/log
     

     Note

     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.

   • nodeC에서 복구를 수행

     이때, 마스터 노드와 슬레이브 노드의 볼륨 경로가 반드시 같아야 한다.

     [nodeC]$ cubrid restoredb -B $CUBRID_DATABASES/testdb/log testdb
     

3. nodeA의 활성 로그(active log)를 nodeC에 복사

   nodeA의 활성 로그에는 최근에 생성된 보관 로그의 번호 정보가 들어 있다. 활성 로그를 복사한 시점 이후에 생성되는 보관 로그가 nodeC의 HA 구동 후 copylogdb에 의해 자동으로 복사되려면 해당 정보가 필요하므로, 사용자는 활성 로그 복사 이전에 생성된 보관 로그만 수동으로 복사하면 된다.

   • nodeC에서 HA 연결을 관리하는 cub_master 구동

     [nodeC]$ cub_master
     

   • nodeA에 대한 copylogdb 프로세스 구동

     [nodeC]$ cubrid heartbeat copylogdb start testdb nodeA
     

   • nodeA의 활성 로그가 복사되었음을 확인

     현 시점의 활성 로그를 복사해 온다는 것은 최근에 생성된 보관 로그 번호 정보를 획득한다는 의미이다. 이후에 생성되는 보관 로그는 [5. nodeC에서 HA 서비스를 구동] 과정 이후 자동으로 복사된다.

     [nodeC]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeC]$ ls
     testdb_lgar_t  testdb_lgat  testdb_lgat__lock
     

   • nodeC에서 nodeA에 대한 copylogdb 프로세스 정지

     [nodeC]$ cubrid heartbeat copylogdb stop testdb nodeA
     

   • nodeC의 cub_master 정지

     [nodeC]$ cubrid service stop
     

4. nodeC에 데이터베이스 복구 이후 필요한 로그 파일 복사

   • nodeB의 복제된 보관 로그(replicated archive log) 전부를 nodeC에 복사

     [nodeC]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeC]$ scp -l 131072 cubrid@nodeB:$CUBRID_DATABASES/testdb_nodeA/testdb_lgar0* .
     

     이 과정에서는 복제에 필요한 복제 보관 로그가 전부 존재해야 한다는 점에 주의한다.

     Note

     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.

     Note

     파일 이름이 숫자로 끝나는 파일만 복사한다. 여기에서는 복제 로그 파일 이름의 번호가 모두 0으로 시작하기 때문에 testdb_lgar0*을 복사했다.

     Note

     필요한 복제 로그가 이미 삭제된 경우 대처 방안

     ha_copy_log_max_archives의 값이 충분히 크지 않은 경우 백업 시각과 활성 로그 생성 시각 사이에 생성된 복제 로그가 삭제될 수 있는데, 이 경우 아래 [5. nodeC에서 HA 서비스를 구동] 과정에서 오류가 발생할 수 있다.

     오류가 발생한 경우, 필요한 로그가 마스터에 존재한다면 추가로 복사해서 nodeC의 HA를 재구동한다. 예를 들어, 마스터에는 보관 로그 #1, #2, #3 이 있고 슬레이브에는 복제된 보관 로그 #2, #3만 존재하며 #1이 추가로 필요하다면 마스터에서 #1을 복사해도 된다. 그러나, 마스터의 보관 로그 파일이 더 많이 남는 경우는 마스터의 log_max_archives 값이 충분히 큰 경우에만 발생할 수 있는 상황이다.

     만약 마스터의 보관 로그에도 원하는 번호의 보관 로그가 없다면 ha_copy_log_max_archives의 값을 충분히 크게 한 후 백업 및 복구를 처음부터 다시 진행한다.

     Note

     필요로 하는 복제 로그 삭제 여부 확인

     필요로 하는 복제 로그가 이미 삭제되었는지 여부는 testdb_lginf 파일을 사용하여 확인할 수 있다.

     1. 슬레이브에서 백업한 데이터베이스를 복원한 경우라면, 복원된 데이터베이스의 db_ha_apply_info 카탈로그 테이블에서 required_lsa_pageid를 통해 마스터 데이터베이스의 어느 페이지부터 필요한지 확인할 수 있다.
     2. 마스터에서 $CUBRID_DATABASES/testdb/log 디렉터리에 있는 testdb_lginf 파일의 내용을 가장 아래에서부터 확인해 나간다.

     Time: 03/16/15 17:44:23.767 - COMMENT: CUBRID/LogInfo for database /home/cubrid/DB/databases/testdb/testdb
     Time: 03/16/15 17:44:23.767 - ACTIVE: /home/cubrid/DB/databases/testdb/log/testdb_lgat 1280 pages
     Time: 03/16/15 17:54:40.892 - ARCHIVE: 0 /home/cubrid/DB/databases/testdb/log/testdb_lgar000 0 1277
     Time: 03/16/15 17:57:29.451 - COMMENT: Log archive /home/cubrid/DB/databases/testdb/log/testdb_lgar000 is not needed any longer unless a database media crash occurs.
     Time: 03/16/15 18:03:08.166 - ARCHIVE: 1 /home/cubrid/DB/databases/testdb/log/testdb_lgar001 1278 2555
     Time: 03/16/15 18:03:08.167 - COMMENT: Log archive /home/cubrid/DB/databases/testdb/log/testdb_lgar000, which contains log pages before 2556, is not needed any longer by any HA utilities.
     Time: 03/16/15 18:03:29.378 - COMMENT: Log archive /home/cubrid/DB/databases/testdb/log/testdb_lgar001 is not needed any longer unless a database media crash occurs.
     

     testdb_lginf 파일의 내용이 위와 같이 기록되어 있을 때, "Time: 03/16/15 17:54:40.892 - ARCHIVE: 0 /home/cubrid/DB/databases/testdb/log/testdb_lgar000 0 1277"의 뒤 두 개의 숫자는 해당 파일이 저장하고 있는 페이지의 시작 ID와 끝 ID이다.

     예를 들어, db_ha_apply_info를 통해 확인한 백업 당시 페이지 ID가 2300번이라면 "testdb_lgar001 1278 2555"을 통해 1278번과 2555번 사이의 페이지 ID임을 확인할 수 있으므로, 복원 시 마스터의 보관 로그 (또는 슬레이브의 복제된 보관 로그)는 1번부터 필요하다는 것을 알 수 있다.

5. nodeC에서 HA 서비스를 구동

   [nodeC]$ cubrid heartbeat start
   

6. nodeA, nodeB의 HA 설정 변경

   • nodeB의 ha_copy_log_max_archive 설정 원복

     [nodeB]$ vi cubrid_ha.conf
     
     ha_copy_log_max_archives=1
     

   • nodeB의 applylogdb 프로세스에 ha_copy_log_max_archives 파라미터 변경 내역 반영

     [nodeB]$ cubrid heartbeat applylogdb stop testdb nodeA
     [nodeB]$ cubrid heartbeat applylogdb start testdb nodeA
     

   • nodeA, nodeB의 cubrid_ha.conf에서 ha_node_list에 nodeC를 추가하고, ha_copy_sync_mode에 sync를 하나 더 추가

     $ cd $CUBRID/conf
     $ vi cubrid_ha.conf
     
     ha_node_list=cubrid@nodeA:nodeB:nodeC
     ha_copy_sync_mode=sync:sync:sync
     

   • 변경된 ha_node_list를 적용

     [nodeA]$ cubrid heartbeat reload
     [nodeB]$ cubrid heartbeat reload
     

     이때, nodeA와 nodeB에서 nodeC에 대한 coplylogdb, applylogdb가 구동된다.

     Note

     9.3 버전의 CUBRID에서는 "cubrid heartbeat reload" 이후 nodeA와 nodeB에서 nodeC에 대한 copylogdb, applylogdb 프로세스를 사용자가 직접 구동해야 하는데, "cubrid heartbeat repl start"를 실행하면 이들이 동시에 구동된다.

7. 브로커 추가 및 응용 프로그램 URL의 altHosts에 추가된 브로커의 호스트 이름 추가

   필요에 따라 브로커를 추가하고, 추가된 브로커에 접속하기 위해 응용 프로그램의 URL 속성인 altHosts에 추가된 브로커의 호스트 이름을 추가한다.

   브로커의 추가를 고려하지 않고 있다면 이 작업을 하지 않아도 된다.

   • nodeA, nodeB 모두 $CUBRID_DATABASES/databases.txt에서 db-host에 nodeC 추가

   #db-name     vol-path                   db-host             log-path                        lob-base-path
   testdb       /home/cubrid/DB/testdb     nodeA:nodeB:nodeC   /home/cubrid/DB/testdb/log      file:/home/cubrid/DB/testdb/lob
   

   databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다. 예를 들어, db-host에 nodeA:nodeB만 쓰거나, localhost만 써도 된다. 다만, 로컬에서 접속하는 경우(csql -u dba testdb@localhost)를 감안하여 db-host에 localhost 또는 로컬 호스트 이름은 반드시 포함한다.

서비스 운영 중 슬레이브 제거¶

"마스터:슬레이브=1:2"로 구성된 환경에서 하나의 슬레이브를 제거해보자.

• nodeA: 마스터 노드 호스트 명
• nodeB: 슬레이브 노드 호스트 명
• nodeC: 제거할 슬레이브 노드 호스트 명

1. nodeC 정지

   $ cubrid heartbeat stop     # heartbeat와 관련된 프로세스들 (applylogdb, copylogdb, cub_server) 정지
   $ cubrid service stop       # cub_master, cub_broker, cub_manager 등의 구동 정지
   

2. nodeA, nodeB의 설정에서 nodeC 제거

• nodeA, nodeB의 cubrid_ha.conf에서 ha_node_list의 nodeC 제거, ha_copy_sync_mode의 sync 하나 제거

  $ vi cubrid_ha.conf
  
  ha_node_list=cubrid@nodeA:nodeB
  ha_copy_sync_mode=sync:sync
  

• 변경된 ha_node_list를 적용

  마스터인 nodeA에는 "reload" 명령을 사용한다.

  [nodeA]$ cubrid heartbeat reload
  

  슬레이브인 nodeB에는 "stop/start" 명령을 사용한다.

  [nodeB]$ cubrid heartbeat stop
  [nodeB]$ cubrid heartbeat start
  

  Note

  9.3 버전의 CUBRID에서는 추가로 nodeC에 대한 copylogdb, applylogdb 프로세스를 사용자가 직접 정지해야 한다. 9.3에서 새로 추가된 명령어인 "cubrid heartbeat repl stop"를 실행하면 copylogdb, applylogdb 프로세스가 동시에 정지된다.

• nodeA, nodeB에서 nodeC에 대한 복제 로그 제거

  $ cd $CUBRID_DATABASES
  $ rm -rf testdb_nodeC
  

• nodeA, nodeB에서 nodeC에 대한 복제 정보 제거

  csql 실행 시 --sysadm 옵션과 --write-on-standby 옵션을 주어야 슬레이브에서 DELETE 연산을 수행할 수 있다.

  $ csql -u dba --sysadm --write-on-standby testdb@localhost
  
  sysadm> DELETE FROM db_ha_apply_info WHERE copied_log_path='/home/cubrid/DB/databases/testdb_nodeC';
  

  copied_log_path는 복제 로그 파일이 저장된 경로를 나타낸다.

3. 브로커 설정에서 nodeC 제거

   • nodeA, nodeB의 databases.txt에서 db-host에 nodeC가 포함되어 있는 경우, nodeC를 제거

     $ cd $CUBRID_DATABASES
     $ vi databases.txt
     
     #db-name     vol-path                   db-host             log-path                        lob-base-path
     testdb       /home/cubrid/DB/testdb     nodeA:nodeB         /home/cubrid/DB/testdb/log      file:/home/cubrid/DB/testdb/lob
     

   • nodeA, nodeB의 브로커 재구동

     $ cubrid broker restart
     

     Note

     nodeC가 종료된 상태이므로 응용 프로그램이 nodeC 데이터베이스에 접속되지는 않을 것이며, 따라서 브로커 재구동을 서두를 필요는 없다. 브로커 재구동 시 해당 브로커에 연결된 응용 프로그램의 연결이 끊어질 수 있음을 감안해야 한다. 또한, 동일한 설정의 브로커가 다중으로 존재하는 경우 하나의 브로커가 다른 브로커를 대신할 수 있으므로 브로커를 하나씩 재구동하도록 한다.

     예를 들어, 위의 설정에서는 nodeA와 nodeB에 브로커가 동일하게 설정되어 있으므로, nodeB를 재구동한 이후 nodeA를 재구동하도록 한다.

서비스 운영 중 레플리카 추가¶

"마스터:슬레이브=1:1" 구성에서 슬레이브를 이용해 레플리카를 추가해 보자. 초기 데이터베이스 설정은 서비스 운영 중 슬레이브 하나 더 추가의 초기 데이터베이스 구축에서 설정한 것과 동일하다.

• nodeA: 마스터 노드 호스트 명
• nodeB: 슬레이브 노드 호스트 명
• nodeC: 새로 추가할 레플리카 노드 호스트 명

0. nodeC의 HA 설정

   • nodeC는 ha_mode를 제외하고는 nodeB와 동일하게 $CUBRID/conf/cubrid.conf 설정

     ha_mode=replica로 설정한다.

     [service]
     service=server,broker,manager
     
     [common]
     
     # HA 구성 시 추가 (HA 모드)
     ha_mode=replica
     

     Note

     레플리카의 트랜잭션 로그는 복제에 사용되지 않으므로, force_remove_log_archives의 설정이 무엇이든 항상 yes로 동작한다.

   • nodeC의 $CUBRID/conf/cubrid_ha.conf 설정

     ha_replica_list에 nodeC를 추가한다.

     [common]
     ha_port_id=59901
     
     # cubrid는 HA 시스템의 그룹 이름이고, nodeA, nodeB, nodeC는 호스트 이름임.
     ha_node_list=cubrid@nodeA:nodeB
     ha_replica_list=cubrid@nodeC
     ha_db_list=testdb
     ha_copy_sync_mode=sync:sync
     ha_apply_max_mem_size=500
     

   • nodeA, nodeB와 동일하게 nodeC의 로캘 라이브러리 설정

     [nodeB]$ scp $CUBRID/conf/cubrid_locales.txt cubrid_usr@nodeC:$CUBRID/conf/.
     [nodeC]$ make_locale.sh -t64
     

   • nodeC의 $CUBRID_DATABASES/databases.txt에서 db-host에 nodeC 지정

     #db-name     vol-path                   db-host             log-path                        lob-base-path
     testdb       /home/cubrid/DB/testdb     nodeC   /home/cubrid/DB/testdb/log      file:/home/cubrid/DB/testdb/lob
     

     databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다. 예를 들어, db-host에 nodeA:nodeB만 쓰거나, localhost만 써도 된다. 다만, 로컬에서 접속하는 경우(csql -u dba testdb@localhost)를 감안하여 db-host에 localhost 또는 로컬 호스트의 이름은 반드시 포함한다.

1. 백업 이후 복구 도중 nodeB의 복제 로그 삭제 방지를 위한 설정 적용

   nodeB에서 백업한 이후 nodeC에 복구하는 도중에도 서비스가 계속된다면, 복구 이후에도 nodeB의 복제 로그가 추가될 수 있는데, 설정에 따라 nodeC에 필요한 복제 로그 일부가 삭제될 수 있다. 이를 방지하기 위해 다음과 같은 설정을 한다.

   • nodeB에 DB 재구동 없이 ha_copy_log_max_archives 값을 크게 변경

     nodeB의 백업 데이터를 복원한 nodeC의 데이터가 마스터(nodeA)와 동일해질 때까지의 트랜잭션이 보관되어야, 백업 시점 이후의 트랜잭션을 nodeC에 반영할 수 있다.

     따라서, 백업 이후 추가된 nodeB의 복제 로그는 유지되어야 한다.

     여기서는 nodeC 구축 시간 동안 수행되는 트랜잭션을 충분히 보관할 수 있는 복제 로그 개수를 5라고 가정한다.

     $CUBRID/conf/cubrid_ha.conf 편집

     ha_copy_log_max_archives=5
     

     nodeB의 applylogdb 프로세스에 ha_copy_log_max_archives 파라미터 변경 내역 반영

     [nodeB]$ cubrid heartbeat applylogdb stop testdb nodeA
     [nodeB]$ cubrid heartbeat applylogdb start testdb nodeA
     

     Note

     마스터 노드인 nodeA만 사용하여 nodeC를 구축한다면 nodeB에서 복제 로그를 복사하는 작업은 불필요하므로, nodeB에서 ha_copy_log_max_archives를 변경하는 작업 역시 불필요하다.

     대신 nodeA에 변경된 log_max_archives를 적용하여야 한다.

     cubrid.conf의 log_max_archives 파라미터는 "SET SYSTEM PARAMETERS" 구문만으로 서비스 중 변경이 가능하다.

     [nodeA]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=5'" testdb@localhost
     

2. nodeB의 백업 및 nodeC의 복구

   • nodeB 백업

     [nodeB]$ cd $CUBRID_DATABASES/testdb/log
     [nodeB]$ cubrid backupdb --sleep-msecs=10 -C -o output.txt testdb@localhost
     

     Note

     서비스 운영 중 슬레이브 하나 더 추가의 --sleep-msecs에 대한 설명을 참고한다.

   • 백업 파일을 nodeC에 복사

     [nodeB]$
     [nodeB]$ scp -l 131072 testdb_bk* cubrid_usr@nodeC:$CUBRID_DATABASES/testdb/log
     
     .. note::
     
     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.
     

   • nodeC에서 복구를 수행

     이때, 마스터 노드와 슬레이브 노드의 볼륨 경로가 반드시 같아야 한다.

     [nodeC]$ cubrid restoredb -B $CUBRID_DATABASES/testdb/log testdb
     

3. nodeA의 활성 로그(active log)를 nodeC에 복사

   nodeA의 활성 로그에는 최근에 생성된 보관 로그의 번호 정보가 들어 있다. 활성 로그를 복사한 시점 이후에 생성되는 보관 로그가 nodeC의 HA 구동 후 copylogdb에 의해 자동으로 복사되려면 이 정보가 필요하므로, 사용자는 활성 로그 복사 이전에 생성된 보관 로그만 수동으로 복사하면 된다.

   • nodeC에서 HA 연결을 관리하는 cub_master 구동

     [nodeC]$ cub_master
     

   • nodeA에 대한 copylogdb 프로세스 구동

     [nodeC]$ cubrid heartbeat copylogdb start testdb nodeA
     

   • nodeA의 활성 로그가 복사되었음을 확인

     현 시점의 활성 로그를 복사해 온다는 것은 현 시점까지 생성된 보관 로그 번호 정보를 획득한다는 의미이다. 이후에 생성되는 보관 로그는 [5. nodeC에서 HA 서비스를 구동] 과정 이후 자동으로 복사된다.

     [nodeC]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeC]$ ls
     testdb_lgar_t  testdb_lgat  testdb_lgat__lock
     

   • nodeC에서 nodeA에 대한 copylogdb 프로세스 정지

     [nodeC]$ cubrid heartbeat copylogdb stop testdb nodeA
     

   • nodeC의 cub_master 정지

     [nodeC]$ cubrid service stop
     

4. nodeC에 데이터베이스 복구 이후 필요한 로그 파일 복사

   • nodeB의 복제된 보관 로그(replicated archive log) 전부를 nodeC에 복사

     [nodeC]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeC]$ scp -l 131072 cubrid@nodeB:$CUBRID_DATABASES/testdb_nodeA/testdb_lgar0* .
     

     이 과정에서는 복제에 필요한 복제 보관 로그가 전부 존재해야 한다는 점에 주의한다.

     Note

     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.

     Note

     파일 이름이 숫자로 끝나는 파일만 복사한다. 여기에서는 복제 로그 파일 이름의 번호가 모두 0으로 시작하기 때문에 testdb_lgar0*을 복사했다.

     Note

     ha_copy_log_max_archives의 값이 충분히 크지 않은 경우 백업 시각과 활성 로그 생성 시각 사이에 생성된 복제 로그가 삭제될 수 있는데, 이 경우 아래 [5. nodeC에서 HA 서비스를 구동] 과정에서 오류가 발생할 수 있다.

     오류가 발생하면 위에서 설명한 필요한 복제 로그의 삭제 여부 확인 및 대처 방안을 참고하여 조치하도록 한다.

5. nodeC에서 HA 서비스를 구동

   [nodeC]$ cubrid heartbeat start
   

6. nodeA, nodeB의 HA 설정 변경

   • nodeB의 ha_copy_log_max_archive 설정 원복

     [nodeB]$ vi cubrid_ha.conf
     
     ha_copy_log_max_archives=1
     

   • nodeB의 applylogdb 프로세스에 ha_copy_log_max_archives 파라미터 변경 내역 반영

     [nodeB]$ cubrid heartbeat applylogdb stop testdb nodeA
     [nodeB]$ cubrid heartbeat applylogdb start testdb nodeA
     

   • nodeA, nodeB의 cubrid_ha.conf에서 ha_replica_list에 nodeC를 추가

     $ cd $CUBRID/conf
     $ vi cubrid_ha.conf
     
     ha_replica_list=cubrid@nodeC
     

   • 변경된 ha_replica_list를 적용

     [nodeA]$ cubrid heartbeat reload
     [nodeB]$ cubrid heartbeat reload
     

     nodeC는 레플리카 노드이므로, nodeA, nodeB에서 nodeC에 대한 applylogdb, copylogdb의 구동은 불필요하다.

7. 브로커 추가 및 응용 프로그램 URL의 altHosts에 추가된 브로커의 호스트 이름 추가

   필요에 따라 브로커를 추가하고, 추가된 브로커에 접속하기 위해 응용 프로그램의 연결 속성에 추가된 브로커의 호스트 이름을 추가한다.

   브로커의 추가를 고려하지 않고 있다면 이 작업을 하지 않아도 된다.

   • nodeA, nodeB 모두 $CUBRID_DATABASES/databases.txt에서 db-host에 nodeC 추가

   #db-name     vol-path                   db-host             log-path                        lob-base-path
   testdb       /home/cubrid/DB/testdb     nodeA:nodeB:nodeC   /home/cubrid/DB/testdb/log      file:/home/cubrid/DB/testdb/lob
   

   databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다. 예를 들어, db-host에 nodeA:nodeB만 쓰거나, localhost만 써도 된다. 다만, 로컬에서 접속하는 경우(csql -u dba testdb@localhost)를 감안하여 db-host에 localhost 또는 로컬 호스트 이름은 반드시 포함한다.

서비스 운영 중 슬레이브 재구축¶

"마스터:슬레이브:레플리카 = 1:1:1"로 구축된 환경에서 슬레이브의 데이터에 이상이 발생했다고 가정하고, 마스터로부터 데이터를 완전히 새로 구축해 보자. 초기 데이터베이스 설정은 서비스 운영 중 슬레이브 하나 더 추가의 초기 데이터베이스 구축에서 설정한 것과 동일하다.

• nodeA: 마스터 노드 호스트 명
• nodeB: 재구축할 슬레이브 노드 호스트 명
• nodeC: 레플리카 노드 호스트 명

1. nodeB 정지, nodeB 데이터 삭제

   nodeB를 정지한 후, nodeB의 데이터베이스 볼륨, nodeA와 nodeC에 있는 nodeB의 복제 로그를 삭제한다.

   • nodeB 정지

     [nodeB]$ cubrid heartbeat stop
     [nodeB]$ cubrid service stop
     

   • nodeB의 데이터베이스 볼륨, 복제 로그 삭제

     [nodeB]$ cd $CUBRID_DATABASES
     [nodeB]$ rm testdb/*
     [nodeB]$ rm testdb/log/*
     
     [nodeB]$ rm -rf testdb_nodeA
     

   • nodeA, nodeC에서 nodeB의 로그 복제 정지

     [nodeA]$ cubrid heartbeat applylogdb stop testdb nodeB
     [nodeA]$ cubrid heartbeat copylogdb stop testdb nodeB
     
     [nodeC]$ cubrid heartbeat applylogdb stop testdb nodeB
     [nodeC]$ cubrid heartbeat copylogdb stop testdb nodeB
     

   • nodeA, nodeC에서 nodeB에 대한 복제 로그 삭제

     [nodeA]$ rm -rf $CUBRID_DATABASES/testdb_nodeB
     [nodeC]$ rm -rf $CUBRID_DATABASES/testdb_nodeB
     

2. HA 카탈로그 테이블 삭제, nodeA의 백업 및 nodeB의 복구, HA 카탈로그 테이블에 정보 추가

   • HA 카탈로그 테이블인 db_ha_apply_info의 레코드 삭제

     nodeB의 db_ha_apply_info 정보를 모두 삭제하여 초기화한다.

     [nodeB]$ csql --sysadm -u dba -S testdb
     csql> DELETE FROM db_ha_apply_info;
     

     nodeA, nodeC에서 nodeB에 대한 db_ha_apply_info 정보를 삭제한다.

     [nodeA]$ csql --sysadm -u dba testdb@localhost
     csql> DELETE FROM db_ha_apply_info WHERE copied_log_path-='/home/cubrid/DB/databases/testdb_nodeB'
     
     [nodeC]$ csql --sysadm --write-on-standby -u dba testdb@localhost
     csql> DELETE FROM db_ha_apply_info WHERE copied_log_path-='/home/cubrid/DB/databases/testdb_nodeB'
     

   • nodeA 백업

     [nodeA]$ cd $CUBRID_DATABASES/testdb/log
     [nodeA]$ cubrid backupdb --sleep-msecs=10 -C -o output.txt testdb@localhost
     

     Note

     서비스 운영 중 슬레이브 하나 더 추가의 --sleep-msecs에 대한 설명을 참고한다.

   • 백업 파일을 nodeB에 복사

     [nodeA]$
     [nodeA]$ scp -l 131072 testdb_bk* cubrid_usr@nodeB:$CUBRID_DATABASES/testdb/log
     

     Note

     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.

   • nodeB에서 복구를 수행

     이때, 마스터 노드와 슬레이브 노드의 볼륨 절대 경로가 반드시 같아야 한다.

     [nodeB]$ cubrid restoredb -B $CUBRID_DATABASES/testdb/log testdb
     

   • nodeB의 db_ha_apply_info에 nodeA에 대한 복제 정보를 추가

     nodeA에 있는 백업 결과를 저장한 output.txt 파일에서 db_ha_apply_info를 업데이트할 정보를 얻는다. output.txt는 "cubrid backupdb" 명령을 수행한 디렉터리에 저장된다.

     [nodeA]$ vi $CUBRID_DATABASES/testdb/log/output.txt
     
     [ Database(testdb) Full Backup start ]
     
     - num-threads: 2
     
     - compression method: NONE
     
     - sleep 10 millisecond per 1M read.
     
     - backup start time: Fri Mar 20 18:18:53 2015
     
     - number of permanent volumes: 2
     
     - HA apply info: testdb 1426495463 12922 16192
     
     - backup progress status
     
     ...
     

   아래 스크립트를 만든 후 이를 수행한다. 위의 출력 정보 중 "HA apply info"에서 첫 번째 숫자인 1426495463은 $db_creation에, 두 번째 숫자인 12922는 $pageid에, 세 번째 숫자인 16192는 $offset에 넣고, db_name에는 데이터베이스 이름인 testdb, master_host에는 마스터 노드의 호스트 이름인 nodeA를 넣는다.

   [nodeB]$ vi update.sh
   
   #!/bin/sh
   
   db_creation=1426495463
   page_id=12922
   offset=16192
   db_name=testdb
   master_host=nodeA
   
   repl_log_home_abs=$CUBRID_DATABASES
   
   repl_log_path=$repl_log_home_abs/${db_name}_${master_host}
   
   local_db_creation=`awk 'BEGIN { print strftime("%m/%d/%Y %H:%M:%S", $db_creation) }'`
       csql_cmd="\
       INSERT INTO \
               db_ha_apply_info \
       VALUES \
       ( \
               '$db_name', \
               datetime '$local_db_creation', \
               '$repl_log_path', \
               $page_id, $offset, \
               $page_id, $offset, \
               $page_id, $offset, \
               $page_id, $offset, \
               $page_id, $offset, \
               $page_id, $offset, \
               NULL, \
               NULL, \
               NULL, \
               0, \
               0, \
               0, \
               0, \
               0, \
               0, \
               0, \
               NULL \
       )"
   
   # Insert nodeA's HA info.
   csql --sysadm -u dba -c "$csql_cmd" -S testdb
   

   [nodeB]$ sh update.sh
   

   입력이 제대로 되었는지 확인한다.

   [nodeB]$ csql -u dba -S testdb
   
   csql> ;line on
   csql> SELECT * FROM db_ha_apply_info;
   

3. nodeA의 활성 로그(active log)를 nodeB에 복사

   nodeA의 활성 로그에는 최근에 생성된 보관 로그의 번호 정보가 들어 있다. 활성 로그를 복사한 시점 이후에 생성되는 보관 로그가 nodeB의 HA 구동 후 copylogdb에 의해 자동으로 복사되려면 해당 정보가 필요하므로, 사용자는 활성 로그 복사 이전에 생성된 보관 로그만 수동으로 복사하면 된다.

   • nodeB에서 HA 연결을 관리하는 cub_master 구동

     [nodeB]$ cub_master
     

   • nodeB에서 nodeA에 대한 copylogdb 프로세스 구동

     [nodeB]$ cubrid heartbeat copylogdb start testdb nodeA
     

   • nodeB에서 nodeA의 활성 로그가 복사되었음을 확인

     현 시점의 활성 로그를 복사해 온다는 것은 현 시점까지 생성된 보관 로그 번호 정보를 획득한다는 의미이다. 이후에 생성되는 보관 로그는 [5. nodeB에서 HA 서비스를 구동] 과정 이후 자동으로 복사된다.

     [nodeB]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeB]$ ls
     testdb_lgar_t  testdb_lgat  testdb_lgat__lock
     

   • nodeB에서 nodeA에 대한 copylogdb 프로세스 정지

     [nodeB]$ cubrid heartbeat copylogdb stop testdb nodeA
     

   • nodeB의 cub_master 정지

     [nodeB]$ cubrid service stop
     

4. nodeB에 데이터베이스 복구 이후 필요한 로그 파일 복사

   • nodeA의 보관 로그 전부를 nodeB에 복사

     [nodeB]$ cd $CUBRID_DATABASES/testdb_nodeA
     [nodeB]$ scp -l 131072 cubrid@nodeA:$CUBRID_DATABASES/testdb/log/testdb_lgar0* .
     

     이 과정에서는 복제에 필요한 보관 로그가 전부 존재해야 한다는 점에 주의한다.

     Note

     scp 명령의 -l 옵션은 복사량을 조절하는 옵션으로, 노드 간 파일 복사 시 I/O 부하를 감안하여 이 옵션을 적절히 부여하도록 한다. 단위는 Kbits이며, 131072는 16MB이다.

     Note

     파일 이름이 숫자로 끝나는 파일만 복사한다. 위의 예에서는 보관 로그가 모두 0으로 시작하기 때문에 testdb_lgar0*을 복사했다.

     Note

     필요한 로그가 이미 삭제된 경우

     log_max_archives의 값이 충분히 크지 않은 경우 백업 시각과 활성 로그 생성 시각 사이에 생성된 보관 로그가 삭제될 수 있는데, 이 경우 아래 [5. nodeB에서 HA 서비스를 구동 ...] 과정에서 오류가 발생할 수 있다.

     이 경우 log_max_archives의 값을 충분히 크게 한 후 백업 및 복구를 처음부터 다시 진행한다.

5. nodeB에서 HA 서비스를 구동하고, nodeA, nodeC에서 로그 복제 및 반영 프로세스 재구동

   [nodeB]$ cubrid heartbeat start
   

   [nodeA]$ cubrid heartbeat applylogdb start testdb nodeB
   [nodeA]$ cubrid heartbeat copylogdb start testdb nodeB
   
   [nodeC]$ cubrid heartbeat applylogdb start testdb nodeB
   [nodeC]$ cubrid heartbeat copylogdb start testdb nodeB
   

복제 불일치 감지 방법¶

마스터 노드와 슬레이브 노드의 데이터가 일치하지 않는 복제 노드 간 데이터 불일치 현상은 다음과 같은 과정을 통해 어느 정도 감지할 수 있다. 그러나, 마스터 노드와 슬레이브 노드의 데이터를 서로 직접 비교해보는 방법보다 더 정확한 확인 방법은 없음에 주의해야 한다. 복제 불일치 상태라는 판단이 서면, 마스터 노드의 데이터베이스를 슬레이브 노드에 새로 구축해야 한다(복제 재구축 스크립트 참고).

• cubrid statdump 명령을 수행하여 Time_ha_replication_delay 시간을 확인한다. 이 값이 클 수록 복제 지연 정도가 클 수 있다는 것을 의미하며, 지연된 시간만큼 복제 불일치가 존재할 가능성이 커진다.

• 슬레이브 노드에서 cubrid applyinfo 를 실행하여 "Fail count" 값을 확인한다. "Fail count"가 0이면, 복제에 실패한 트랜잭션이 없다고 볼 수 있다(cubrid applyinfo 참고).

  [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb
  
   *** Applied Info. ***
  Committed page                 : 1913 | 2904
  Insert count                   : 645
  Update count                   : 0
  Delete count                   : 0
  Schema count                   : 60
  Commit count                   : 15
  Fail count                     : 0
  ...
  

• 슬레이브 노드에서 복제 로그의 복사 지연 여부를 확인하기 위해, cubrid applyinfo 를 실행하여 "Copied Active Info."의 "Append LSA" 값과 "Active Info."의 "Append LSA" 값을 비교한다. 이 값이 큰 차이를 보인다면, 복제 로그가 슬레이브 노드에 복사되는데 지연이 있다는 의미이다(cubrid applyinfo 참고).

  [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb
  
  ...
  
   *** Copied Active Info. ***
  DB name                        : testdb
  DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)
  EOF LSA                        : 1913 | 2976
  Append LSA                     : 1913 | 2976
  HA server state                : active
  
   ***  Active Info. ***
  DB name                        : testdb
  DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)
  EOF LSA                        : 1913 | 2976
  Append LSA                     : 1913 | 2976
  HA server state                : active
  

• 복제 로그 복사 지연이 의심되는 경우 네트워크 회선 속도가 느려졌는지, 디스크 여유 공간이 충분한지, 디스크 I/O에는 이상이 없는지 등을 확인한다.

• 슬레이브 노드에서 복제 로그의 반영 지연 여부를 확인하기 위해, cubrid applyinfo 를 실행하여 "Applied Info." 의 "Committed page" 값과 "Copied Active Info."의 "EOF LSA" 값을 비교한다. 이 값이 큰 차이를 보인다면, 복제 로그가 슬레이브 데이터베이스를 반영하는데 지연이 있다는 의미이다(cubrid applyinfo 참고).

  [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb
  
   *** Applied Info. ***
  Committed page                 : 1913 | 2904
  Insert count                   : 645
  Update count                   : 0
  Delete count                   : 0
  Schema count                   : 60
  Commit count                   : 15
  Fail count                     : 0
  
   *** Copied Active Info. ***
  DB name                        : testdb
  DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)
  EOF LSA                        : 1913 | 2976
  Append LSA                     : 1913 | 2976
  HA server state                : active
  ...
  

• 복제 로그 반영 지연이 심한 경우 수행 시간이 긴 트랜잭션을 의심해 볼 수 있는데, 해당 트랜잭션의 수행이 정상이라면 복제 지연 역시 정상적으로 발생할 수 있다. 정상 여부를 판단하기 위해 cubrid applyinfo 를 지속적으로 수행하면서 applylogdb가 복제 로그를 슬레이브 노드에 계속 반영하고 있는지 확인해야 한다.

• copylogdb, applylogdb 프로세스가 생성한 오류 로그의 메시지를 확인한다(오류 메시지 참고).

• 마스터 데이터베이스 테이블의 레코드 개수, 슬레이브 데이터베이스 테이블의 레코드 개수를 비교한다.

HA 오류 메시지¶

다음은 복제 불일치 발생의 원인이 될 수 있는 오류에 대한 오류 메시지들을 정리한 것이다.

ha_make_slavedb.sh 스크립트¶

ha_make_slavedb.sh 스크립트를 이용하여 복제 재구축을 수행할 수 있다. 이 스크립트는 $CUBRID/share/scripts/ha 에 위치하며, 복제 재구축에 들어가기 전에 다음의 항목을 사용자 환경에 맞게 설정해야 한다. 이 스크립트는 2008 R2.2 Patch 9 버전부터 지원하지만 2008 R4.1 Patch 2 미만 버전과는 일부 설정 방법이 다르며, 이 문서에서는 2008 R4.1 Patch 2 이상 버전에서의 설정 방법에 대해 설명한다.

• target_host : 복제 재구축을 위한 원본 노드(주로 마스터 노드)의 호스트명으로, /etc/hosts에 등록되어 있어야 한다. 슬레이브 노드는 마스터 노드 또는 레플리카 노드를 원본으로 하여 복제 재구축이 가능하며, 레플리카 노드는 슬레이브 노드 또는 또 다른 레플리카 노드를 원본으로 하여 복제 재구축이 가능하다.
• repl_log_home : 마스터 노드의 복제 로그의 홈 디렉터리를 설정한다. 일반적으로 $CUBRID_DATABASES 와 동일하다. 반드시 절대 경로를 입력해야 하며, 심볼릭 링크를 사용하면 안 된다. 경로 뒤에 슬래시(/)를 붙이면 안 된다.

다음은 필요에 따라 선택적으로 설정하는 항목이다.

• db_name : 복제 재구축할 데이터베이스 이름을 설정한다. 설정하지 않으면 $CUBRID/conf/cubrid_ha.conf 내 ha_db_list 의 가장 처음에 위치한 이름을 사용한다.
• backup_dest_path : 복제 원본 노드에서 backupdb 수행 시 백업 볼륨을 생성할 경로를 설정한다.
• backup_option : 복제 원본 노드에서 backupdb 수행 시 필요한 옵션을 설정한다.
• restore_option : 복제 대상 노드에서 restoredb 수행 시 필요한 옵션을 설정한다.
• scp_option : 복제 원본 노드의 백업 볼륨을 복제 대상 노드로 복사해 오기 위한 scp 옵션을 설정할 수 있는 항목으로 기본값은 복제 원본 노드의 네트워크 부하를 주지 않기 위해 -l 131072 옵션을 사용한다(전송 속도를 16M로 제한).

스크립트의 설정이 끝나면 ha_make_slavedb.sh 스크립트를 복제 대상 노드에서 수행한다. 스크립트 수행 시 여러 단계에 의해 복제 재구축이 이루어지며 각 단계의 진행을 위해서 사용자가 적절한 값을 입력해야 한다. 다음은 입력할 수 있는 값에 대한 설명이다.

• yes : 계속 진행한다.
• no : 현재 단계를 포함하여 이후 과정을 진행하지 않는다.
• skip : 현재 단계를 수행하지 않고 다음 단계를 진행한다. 이 입력 값은 이전 스크립트 수행에 실패하여 재시도할 때 다시 수행할 필요가 없는 단계를 무시하기 위해 사용한다.

마스터에서 슬레이브 구축¶

다음은 복제 재구축 원본 노드를 마스터 노드로 하여, 마스터 노드로부터 슬레이브 노드를 새로 구축하거나 재구축하는 예이다. 새로 구축하는 경우 Master:Slave는 1:0에서 1:1이 된다.

• 마스터 노드 호스트 명: nodeA
• 슬레이브 노드 호스트 명: nodeB

복제 재구축은 시스템이 운영 중인 상태에서도 수행할 수 있으나, 복제 지연을 최소화하기 위해 시간 당 트랜잭션 수가 적을 때 수행하는 것을 권장한다.

ha_make_slavedb.sh 스크립트를 실행하기 전에 다음을 수행한다.

1. nodeB의 HA 서비스를 종료한다. 슬레이브를 새로 구축한다면 이 과정은 불필요하다.

   [nodeB]$ cubrid heartbeat stop
   

2. nodeB를 새로 구축한다면 환경 설정을 참고하여 nodeA와 nodeB의 cubrid.conf, cubrid_ha.conf, cubrid_broker.conf, databases.txt를 설정한다.

   • nodeA와 nodeB의 cubrid.conf에 설정

     ha_mode=on
     force_remove_log_archives=no
     

   • nodeA에 DB의 재구동 없이 log_max_archives 적용

     슬레이브 구축 시간 동안 수행되는 트랜잭션을 보관할 수 있는 보관 로그(archive logs) 개수를 10이라고 가정한다. "SET SYSTEM PARAMETERS" 문을 사용하여 "10"으로 설정하며, cubrid.conf의 log_max_archives는 nodeB의 구축/재구축 이후 기존 설정을 사용할 것이므로 변경하지 않는다.

     [nodeA]$ csql -u dba -c "SET SYSTEM PARAMETERS 'force_remove_log_archives=no'" testdb@localhost
     [nodeA]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=10'" testdb@localhost
     

   • nodeA의 cubrid_ha.conf에 설정

     ha_node_list에 nodeB를 추가한 후 마스터 노드에서 HA 서비스를 구동해 놓으면 슬레이브 노드가 구동되기 전까지 마스터 노드에서 쓰기 작업을 할 수 없게 되므로 nodeA만 추가한다.

     ha_node_list=cubrid@nodeA
     

   • databases.txt의 db-host 설정

     nodeA:nodeB
     

     하지만 databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다.

3. nodeB에서 ha_make_slavedb.sh 스크립트를 설정해야 한다. target_host에는 복사 원본, 즉 마스터 노드의 호스트 이름(nodeA)을 설정하고, repl_log_home에는 복제 로그의 홈 디렉터리(기본값: $CUBRID_DATABASES)를 설정한다.

   [nodeB]$ cd $CUBRID/share/scripts/ha
   [nodeB]$ vi ha_make_slavedb.sh
   target_host=nodeA
   

4. 설정 후에는 다음과 같이 슬레이브에서 ha_make_slavedb.sh 스크립트를 실행한다.

   [nodeB]$ cd $CUBRID/share/scripts/ha
   [nodeB]$ ./ha_make_slavedb.sh
   

ha_make_slavedb.sh 스크립트를 각 단계의 순서대로 실행하는 도중 오류가 발생하거나 n을 입력하여 실행을 중단한 이후에 재실행할 경우, 그 이전까지 실행에 성공한 단계에 대해서는 s를 입력하여 다음 단계로 넘어가도 된다.

1. HA 복제 재구축을 위한 Linux 계정의 암호와, CUBRID DB 계정인 dba 의 암호를 입력하는 단계이다. 질문에 y를 입력한다.

   ##### step 1 ###################################################################
   #
   # get HA/replica user password and DBA password
   #
   #  * warning !!!
   #   - Because ha_make_slavedb.sh uses expect (ssh, scp) to control HA/replica node,
   #     the script has to know these passwords.
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

   HA 노드의 Linux 계정 암호와, CUBRID DB 계정인 dba 의 암호를 입력한다. 처음 CUBRID 설치 후 dba 암호를 변경하지 않았을 경우, dba 암호의 입력 없이 <Enter> 키를 누르면 된다.

   HA/replica cubrid_usr's password :
   HA/replica cubrid_usr's password :
   
   testdb's DBA password :
   Retype testdb's DBA password :
   

2. 슬레이브 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   ##### step 2 ###################################################################
   #
   #  ha_make_slavedb.sh is the script for making slave database more easily
   #
   #  * environment
   #   - db_name           : testdb
   #
   #   - master_host       : nodeA
   #   - slave_host        : nodeB
   #   - replica_hosts     :
   #
   #   - current_host      : nodeB
   #   - current_state     : slave
   #
   #   - target_host       : nodeA
   #   - target_state      : master
   #
   #   - repl_log_home     : /home/cubrid_usr/CUBRID/databases
   #   - backup_dest_path  : /home/cubrid_usr/.ha/backup
   #   - backup_option     :
   #   - restore_option    :
   #
   #  * warning !!!
   #   - environment on slave must be same as master
   #   - database and replication log on slave will be deleted
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

3. 슬레이브 노드의 HA 관련 스크립트들을 마스터 노드에 복사하는 단계이다. 질문에 y를 입력한다. 이후 scp 명령을 이용하여 필요한 파일을 전송할 때 ssh-keygen으로 공개 키를 설정하지 않았으면 암호가 요구된다.

   ##### step 3 ###################################################################
   #
   #  copy scripts to master node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeA(master).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

4. HA 관련 스크립트들을 레플리카 노드에 복사하는 단계이다. 이 시나리오에서는 레플리카 노드가 없으므로 이 단계는 s를 입력하여 다음 단계로 넘어가도 된다.

   ##### step 4 #####################################
   #
   #  copy scripts to replication node
   #
   #  * details
   #   - scp scripts to '~/.ha' on replication node.
   #
   ##################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   
   There is no replication server to copy scripts to.
   

5. 모든 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   expect 명령이 설치(root 계정에서 yum install expect)되어 있지 않으면 이 단계에서 오류가 발생할 수 있다.

   ##### step 5 ###################################################################
   #
   #  check environment of all ha nodes
   #
   #  * details
   #   - test $CUBRID == /home1/cubrid_usr/CUBRID
   #   - test $CUBRID_DATABASES == /home1/cubrid_usr/CUBRID/database
   #   - test -d /home1/cubrid_usr/CUBRID/database/testdb
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

6. 마스터 노드의 복제를 중단하는 단계이다. 질문에 y를 입력한다.

   ##### step 6 ###################################################################
   #
   #  suspend copylogdb/applylogdb on master if running
   #
   #  * details
   #   - deregister copylogdb/applylogdb on nodeA(master).
   #
   ################################################################################
      continue ? ([y]es / [n]o / [s]kip) : y
   

7. 이전에 슬레이브 노드에 존재했던 오래된 복제 로그를 삭제하고 마스터 노드의 HA 메타 정보 테이블을 초기화하는 단계이다. 질문에 y를 입력한다.

   ##### step 7 ###################################################################
   #
   #  remove old copy log of slave and init db_ha_apply_info on master
   #
   #  * details
   #   - remove old copy log of slave
   #   - init db_ha_apply_info on master
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

8. 레플리카 노드의 HA 메타 정보 테이블을 초기화하는 단계이다. 이 시나리오에서는 레플리카 노드가 없으므로 질문에 s를 입력하여 넘어가도 된다.

   ##### step 8 ###################################################################
   #
   #  remove old copy log of slave and init db_ha_apply_info on replications
   #
   #  * details
   #   - remove old copy log of slave
   #   - init db_ha_apply_info on replications
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   
   There is no replication server to init ha_info
   

9. HA 복제 재구축을 위해 마스터 노드(target_host)로부터 백업 볼륨을 생성하는 단계로서, 기존에 이미 생성한 백업 볼륨이 있다면 s를 입력하여 다음 단계로 넘어갈 수 있다. 기존 백업 볼륨을 사용하여 복제 재구축을 수행하기 위해서는 다음과 같은 제약 조건이 있다.

   • 백업 시 실행 중인 트랜잭션을 포함하는 보관 로그(archive logs)가 반드시 마스터 노드(target_host) 내에 존재해야 한다(즉, 오래 전에 생성한 백업 볼륨은 사용할 수 없음).
   • 백업 시 -o 옵션을 사용하여 백업 상태 정보 파일을 남겨야 한다. 이때 저장되는 경로는 백업 볼륨 파일의 경로와 같아야 한다. 파일 이름은 db_name.bkup.output 형식이어야 하며, 파일 이름이 다른 경우 스크립트 수행 전에 형식에 맞게 변경한다.
   • 기존 백업 볼륨 및 상태 정보 파일의 경로는 스크립트 내의 backup_dest_path 파라미터에 지정해야 한다. 즉, 마스터 노드(target_host)에 존재하는 백업 볼륨이 포함된 디렉터리의 절대 경로를 이 파라미터에 지정하면 된다.

   ##### step 9 ###################################################################
   #
   #  online backup database  on master
   #
   #  * details
   #   - run 'cubrid backupdb -C -D ... -o ... testdb@localhost' on master
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

10. 마스터 노드의 데이터베이스 백업본을 슬레이브 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 10 ###################################################################
    #
    #  copy testdb databases backup to current host
    #
    #  * details
    #   - scp databases.txt from target host if there's no testdb info on current host
    #   - remove old database and replication log if exists
    #   - make new database volume and replication path
    #   - scp  database backup to current host
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

11. 복사한 데이터베이스 백업본을 슬레이브 노드에 복구하는 단계이다. 질문에 y를 입력한다.

    ##### step 11 ###################################################################
    #
    #  restore database testdb on current host
    #
    #  * details
    #   - cubrid restoredb -B ... testdb current host
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

12. 슬레이브 노드의 HA 메타 정보 테이블 값을 설정하는 단계이다. 질문에 y를 입력한다.

    ##### step 12 ###################################################################
    #
    #  set db_ha_apply_info on slave
    #
    #  * details
    #   - insert db_ha_apply_info on slave
    #
    ################################################################################
    
        continue ? ([y]es / [n]o / [s]kip) : y
    

13. 마스터에 있는 복제 로그를 초기화하고, 마스터 노드의 보관 로그를 슬레이브 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 13 ###################################################################
    #
    #  make initial replication active log on master, and copy archive logs from
    #  master
    #
    #  * details
    #   - remove old replication log on master if exist
    #   - start copylogdb to make replication active log
    #   - copy archive logs from master
    #
    ################################################################################
    
        continue ? ([y]es / [n]o / [s]kip) : y
    

14. 마스터 노드의 복제를 재시작하는 단계이다. 질문에 y를 입력한다.

    ##### step 14 ###################################################################
    #
    #  restart copylogdb/applylogdb on master
    #
    #  * details
    #   - restart copylogdb/applylogdb
    #
    ################################################################################
    
        continue ? ([y]es / [n]o / [s]kip) : y
    

15. 슬레이브 노드 구축이 정상적으로 완료되었는지 여부를 출력하는 단계이다.

    ##### step 15 ##################################################################
    #
    #  completed
    #
    ################################################################################
    

ha_make_slavedb.sh 스크립트의 수행이 완료되면 다음 작업을 수행한다.

• 슬레이브를 새로 구축하는 경우 다음과 같이 마스터와 슬레이브의 ha_node_list에 nodeB를 추가한다.

  • 마스터와 슬레이브의 cubrid_ha.conf에 "ha_node_list=cubrid@nodeA:nodeB"를 설정한다.

  • 마스터에서 cubrid heartbeat reload 명령을 실행하여 ha_node_list 정보를 다시 읽는다.

  • 다음과 같이 마스터의 보관 로그 개수인 log_max_archives 설정을 cubrid.conf에 지정된 값으로 재설정한다.

    $ csql --sysadm -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=0'" testdb@localhost
    

• 슬레이브 노드에서 HA 상태를 확인하고, cubrid heartbeat start 명령으로 HA를 구동한다.

  [NodeB]$ cubrid heartbeat status
  @ cubrid heartbeat status
  ++ cubrid master is not running.
  
  [NodeB]$ cubrid heartbeat start
  @ cubrid heartbeat start
  @ cubrid master start
  ++ cubrid master start: success
  
  @ HA processes start
  @ cubrid server start: testdb
  
  This may take a long time depending on the amount of recovery works to do.
  
  CUBRID 9.2
  
  ++ cubrid server start: success
  @ copylogdb start
  ++ copylogdb start: success
  @ applylogdb start
  ++ applylogdb start: success
  ++ HA processes start: success
  ++ cubrid heartbeat start: success
  
  [nodeB]$ cubrid heartbeat status
  @ cubrid heartbeat status
  
  HA-Node Info (current nodeB, state slave)
  Node nodeB (priority 2, state slave)
  Node nodeA (priority 1, state master)
  
  HA-Process Info (master 26611, state slave)
  Applylogdb testdb@nodeA:/home/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 26831, state registered)
  Copylogdb testdb@nodeA:/home/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 26829, state registered)
  Server testdb (pid 26617, state registered_and_standby)
  

• cubrid_broker.conf를 참고하여 브로커를 설정하고, cubrid broker restart 명령으로 브로커를 구동한다.

슬레이브에서 레플리카 구축¶

다음은 복제 재구축 원본 노드를 슬레이브 노드로 하여, 슬레이브 노드에서 레플리카 노드를 새로 구축하거나 재구축하는 예이다. 새로 구축하는 경우 Master:Slave:Replica는 1:1:0에서 1:1:1이 된다.

• 마스터 노드 호스트 명: nodeA
• 슬레이브 노드 호스트 명: nodeB
• 레플리카 노드 호스트 명: nodeC

복제 재구축은 시스템이 운영 중인 상태에서도 수행할 수 있으나, 복제 지연을 최소화하기 위해 시간 당 트랜잭션 수가 적을 때 수행하는 것을 권장한다.

ha_make_slavedb.sh 스크립트를 실행하기 전에 다음을 수행한다.

1. nodeC의 HA 서비스를 종료한다. nodeC를 새로 구축한다면 이 과정은 불필요하다.

   [nodeC]$ cubrid heartbeat stop
   [nodeC]$ cubrid service stop
   

2. nodeC를 새로 구축한다면 환경 설정을 참고하여 nodeA, nodeB, nodeC의 cubrid.conf, cubrid_ha.conf, cubrid_broker.conf, databases.txt를 설정한다.

   • nodeC의 cubrid.conf에 설정

     ha_mode=replica
     

   • 모든 노드의 cubrid_ha.conf에 설정

     ha_node_list=cubrid@nodeA:nodeB
     ha_replica_list=cubrid@nodeC
     

   • 모든 노드에서 databases.txt의 db-host 설정

     nodeA:nodeB:nodeC
     

     하지만 databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다.

3. nodeB에 DB의 재구동 없이 log_max_archives의 변경된 값을 적용한다.

   레플리카 구축 시간 동안 수행되는 트랜잭션을 보관할 수 있는 보관 로그(archive logs) 개수를 10이라고 가정한다. "SET SYSTEM PARAMETERS" 문을 사용하여 "10"으로 설정하며, cubrid.conf의 log_max_archives는 nodeC의 구축/재구축 이후 기존 설정을 사용할 것이므로 변경하지 않는다.

   [nodeB]$ csql -u dba -c "SET SYSTEM PARAMETERS 'force_remove_log_archives=no'" testdb@localhost
   [nodeB]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=10'" testdb@localhost
   

4. nodeC의 ha_make_slavedb.sh 스크립트를 설정해야 한다. target_host에는 복사할 원본, 즉 nodeB를 설정하고, repl_log_home에는 복제 로그의 홈 디렉터리(기본값: $CUBRID_DATABASES)를 설정한다.

   [nodeC]$ cd $CUBRID/share/scripts/ha
   [nodeC]$ vi ha_make_slavedb.sh
   target_host=nodeB
   

5. 설정 후에는 nodeC에서 ha_make_slavedb.sh 스크립트를 실행한다.

   [nodeC]$ cd $CUBRID/share/scripts/ha
   [nodeC]$ ./ha_make_slavedb.sh
   

ha_make_slavedb.sh 스크립트를 각 단계의 순서대로 실행하는 도중 오류가 발생하거나 n을 입력하여 실행을 중단한 이후에 재실행할 경우, 그 이전까지 실행에 성공한 단계에 대해서는 s를 입력하여 다음 단계로 넘어가도 된다.

1. HA 복제 재구축을 위한 Linux 계정의 암호와, CUBRID DB 계정인 dba 의 암호를 입력하는 단계이다. 질문에 y를 입력한다.

   ##### step 1 ###################################################################
   #
   # get HA/replica user password and DBA password
   #
   #  * warning !!!
   #   - Because ha_make_slavedb.sh uses expect (ssh, scp) to control HA/replica node,
   #     the script has to know these passwords.
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

   HA 노드의 Linux 계정 암호와, CUBRID DB 계정인 dba 의 암호를 입력한다. 처음 CUBRID 설치 후 dba 암호를 변경하지 않았을 경우, dba 암호의 입력 없이 <Enter> 키를 누르면 된다.

   HA/replica cubrid_usr's password :
   HA/replica cubrid_usr's password :
   
   testdb's DBA password :
   Retype testdb's DBA password :
   

2. 레플리카 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   ##### step 2 ###################################################################
   #
   #  ha_make_slavedb.sh is the script for making slave database more easily
   #
   #  * environment
   #   - db_name           : testdb
   #
   #   - master_host       : nodeA
   #   - slave_host        : nodeB
   #   - replica_hosts     : nodeC
   #
   #   - current_host      : nodeC
   #   - current_state     : replica
   #
   #   - target_host       : nodeB
   #   - target_state      : slave
   #
   #   - repl_log_home     : /home/cubrid_usr/CUBRID/databases
   #   - backup_dest_path  : /home/cubrid_usr/.ha/backup
   #   - backup_option     :
   #   - restore_option    :
   #
   #  * warning !!!
   #   - environment on slave must be same as master
   #   - database and replication log on slave will be deleted
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

3. 레플리카 노드의 HA 관련 스크립트들을 마스터 노드에 복사하는 단계이다. 질문에 y를 입력한다. 이후 모든 단계에서도 마스터 노드에 접속 시 암호를 요구하게 되며, scp 명령을 이용하여 필요한 파일을 전송할 때에도 암호를 요구한다.

   ##### step 3 ###################################################################
   #
   #  copy scripts to master node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeA(master).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

4. 레플리카 노드의 HA 관련 스크립트들을 슬레이브 노드에 복사하는 단계이다.

   ##### step 4 #####################################
   #
   #  copy scripts to slave node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeB().
   #
   ##################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

5. 모든 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   expect 명령이 설치(root 계정에서 yum install expect)되어 있지 않으면 이 단계에서 오류가 발생할 수 있다.

   ##### step 5 ###################################################################
   #
   #  check environment of all ha nodes
   #
   #  * details
   #   - test $CUBRID == /home1/cubrid_usr/CUBRID
   #   - test $CUBRID_DATABASES == /home1/cubrid_usr/CUBRID/database
   #   - test -d /home1/cubrid_usr/CUBRID/database/testdb
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

6. HA 복제 재구축을 위해 슬레이브 노드(target_host)로부터 백업 볼륨을 생성하는 단계로서, 기존에 이미 생성한 백업 볼륨이 있다면 s를 입력하여 다음 단계로 넘어갈 수 있다. 기존 백업 볼륨을 사용하여 복제 재구축을 수행하기 위해서는 다음과 같은 제약 조건이 있다.

   • 백업 시작 이후 생성된 보관 로그(archive logs), 원본 DB에 미반영된 복제 로그와 복제 재구축 이후 진행 중인 트랜잭션에 대한 복제 로그가 반드시 슬레이브 노드(target_host) 내에 존재해야 한다(즉, 오래 전에 생성한 백업 볼륨은 사용할 수 없음).
   • 백업 시 -o 옵션을 사용하여 백업 상태 정보 파일을 남겨야 한다. 이때 저장되는 경로는 백업 볼륨 파일의 경로와 같아야 한다. 파일 이름은 db_name.bkup.output 형식이어야 하며, 파일 이름이 다른 경우 스크립트 수행 전에 형식에 맞게 변경한다.
   • 기존 백업 볼륨 및 상태 정보 파일의 경로는 스크립트 내의 backup_dest_path 파라미터에 지정해야 한다. 즉, 슬레이브 노드(target_host)에 존재하는 백업 볼륨이 포함된 디렉터리의 절대 경로를 이 파라미터에 지정하면 된다.

   ##### step 6 ###################################################################
   #
   #  online backup database on slave
   #
   #  * details
   #   - run 'cubrid backupdb -C -D ... -o ... testdb@localhost' on slave
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

7. 슬레이브 노드의 데이터베이스 백업본을 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

   ##### step 7 ###################################################################
   #
   #  copy testdb databases backup to current host
   #
   #  * details
   #   - scp databases.txt from target host if there's no testdb info on current host
   #   - remove old database and replication log if exist
   #   - make new database volume and replication path
   #   - scp  database backup to current host
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

8. 복사한 데이터베이스 백업본을 레플리카 노드에 복구하는 단계이다. 질문에 y를 입력한다.

   ##### step 8 ###################################################################
   #
   #  restore database testdb on current host
   #
   #  * details
   #   - cubrid restoredb -B ... testdb current host
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

9. 마스터에 있는 복제 로그를 초기화하고, 마스터 노드의 보관 로그를 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

   ##### step 9 ###################################################################
   #
   #  make initial replication active log on master, and copy archive logs from
   #  master
   #
   #  * details
   #   - remove old replication log on master if exist
   #   - start copylogdb to make replication active log
   #   - copy archive logs from master
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

10. 슬레이브에 있는 복제 로그를 초기화하고, 슬레이브 노드의 보관 로그를 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 10 ###################################################################
    #
    #  make initial replication active log on slave, and copy archive logs from
    #  slave
    #
    #  * details
    #   - remove old replication log on slave if exists
    #   - start copylogdb to make replication active log
    #   - copy archive logs from slave
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

11. 레플리카 노드 구축이 정상적으로 완료되었는지 여부를 출력하는 단계이다.

    ##### step 11 ##################################################################
    #
    #  completed
    #
    ################################################################################
    

ha_make_slavedb.sh 스크립트의 수행이 완료되면 다음 작업을 수행한다.

• 레플리카 노드를 새로 구축하는 경우 nodeA와 nodeB에서 변경된 cubrid_ha.conf의 ha_node_list, ha_replica_list를 적용한다.

  [nodeA]$ cubrid heartbeat reload
  

  [nodeB]$ cubrid heartbeat reload
  

• 슬레이브 노드에서 log_max_archives 설정을 cubrid.conf에 지정된 값으로 재설정한다.

  $ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=0'" testdb@localhost
  

• 레플리카 노드에서 HA 상태를 확인하고, cubrid heartbeat start 명령으로 HA를 구동한다.

  [nodeC]$ cubrid hb status
  @ cubrid heartbeat status
  
   HA-Node Info (current nodeC, state unknown)
  
  
   HA-Process Info (master 5214, state unknown)
  
  [nodeC]$ cubrid hb start
  @ cubrid heartbeat start
  @ cubrid master start
  ++ cubrid master is running.
  @ HA processes start
  @ cubrid server start: testdb
  
  This may take a long time depending on the amount of recovery works to do.
  
  CUBRID 9.2
  
  ++ cubrid server start: success
  @ copylogdb start
  ++ copylogdb start: success
  @ applylogdb start
  ++ applylogdb start: success
  ++ HA processes start: success
  ++ cubrid heartbeat start: success
  
  [nodeC]$ cubrid hb status
  @ cubrid heartbeat status
  
   HA-Node Info (current nodeC, state replica)
     Node nodeC (priority 32767, state replica)
     Node nodeB (priority 2, state slave)
     Node nodeA (priority 1, state master)
  
  
   HA-Process Info (master 5214, state slave)
     Applylogdb testdb@nodeB:/home1/cubrid_usr/CUBRID/databases/testdb_nodeB (pid 5816, state registered)
     Applylogdb testdb@nodeA:/home1/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 5814, state registered)
     Copylogdb testdb@nodeB:/home1/cubrid_usr/CUBRID/databases/testdb_nodeB (pid 5812, state registered)
     Copylogdb testdb@nodeA:/home1/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 5810, state registered)
     Server testdb (pid 5590, state registered_and_standby)
  

• cubrid_broker.conf를 참고하여 브로커를 설정하고, cubrid broker restart 명령으로 브로커를 구동한다.

레플리카에서 레플리카 구축¶

다음은 복제 재구축 원본 노드를 레플리카 노드로 하여, 레플리카 노드로부터 레플리카 노드를 새로 구축하거나 재구축하는 예이다. 새로 구축하는 경우 Master:Slave:Replica는 1:1:1에서 1:1:2가 된다.

• 마스터 노드 호스트 명: nodeA
• 슬레이브 노드 호스트 명: nodeB
• 레플리카 노드 호스트 명: nodeC
• 레플리카 노드 호스트 명: nodeD

복제 재구축은 마스터 노드가 운영 중인 상태에서도 수행할 수 있으나, 복제 지연을 최소화하기 위해 시간 당 트랜잭션 수가 적을 때 수행하는 것을 권장한다.

ha_make_slavedb.sh 스크립트를 실행하기 전에 다음을 수행한다.

1. nodeD의 HA 서비스를 종료한다. nodeD를 새로 구축한다면 이 과정은 불필요하다.

   [nodeD]$ cubrid heartbeat stop
   [nodeD]$ cubrid service stop
   

2. nodeD를 새로 구축한다면 환경 설정을 참고하여 nodeA, nodeB, nodeC, nodeD의 cubrid.conf, cubrid_ha.conf, cubrid_broker.conf, databases.txt를 설정한다.

   • nodeC, nodeD의 cubrid.conf에 설정

     ha_mode=replica
     

   • 모든 노드의 cubrid_ha.conf에 설정

     ha_node_list=cubrid@nodeA:nodeB
     ha_replica_list=cubrid@nodeC:nodeD
     

   • 모든 노드에서 databases.txt의 db-host 설정

     nodeA:nodeB:nodeC:nodeD
     

     하지만 databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다.

3. nodeC에 DB의 재구동 없이 log_max_archives의 변경된 값을 적용한다.

   레플리카 구축 시간 동안 수행되는 트랜잭션을 보관할 수 있는 보관 로그(archive logs) 개수를 10이라고 가정한다. "SET SYSTEM PARAMETERS" 문을 사용하여 "10"으로 설정하며, cubrid.conf의 log_max_archives는 nodeD의 구축/재구축 이후 기존 설정을 사용할 것이므로 변경하지 않는다.

   [nodeC]$ csql -u dba -c "SET SYSTEM PARAMETERS 'force_remove_log_archives=no'" testdb@localhost
   [nodeC]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=10'" testdb@localhost
   

4. nodeD의 ha_make_slavedb.sh 스크립트를 설정해야 한다. target_host에는 복사할 원본, 즉 nodeC를 설정하고, repl_log_home에는 복제 로그의 홈 디렉터리(기본값: $CUBRID_DATABASES)를 설정한다.

   [nodeD]$ cd $CUBRID/share/scripts/ha
   [nodeD]$ vi ha_make_slavedb.sh
   target_host=nodeC
   

5. 설정 후에는 nodeD에서 ha_make_slavedb.sh 스크립트를 실행한다.

   [nodeD]$ cd $CUBRID/share/scripts/ha
   [nodeD]$ ./ha_make_slavedb.sh
   

ha_make_slavedb.sh 스크립트를 각 단계의 순서대로 실행하는 도중 오류가 발생하거나 n을 입력하여 실행을 중단한 이후에 재실행할 경우, 그 이전까지 실행에 성공한 단계에 대해서는 s를 입력하여 다음 단계로 넘어가도 된다.

1. HA 복제 재구축을 위한 Linux 계정의 암호와, CUBRID DB 계정인 dba 의 암호를 입력하는 단계이다. 질문에 y를 입력한다.

   ##### step 1 ###################################################################
   #
   # get HA/replica user password and DBA password
   #
   #  * warning !!!
   #   - Because ha_make_slavedb.sh uses expect (ssh, scp) to control HA/replica node,
   #     the script has to know these passwords.
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

   HA 노드의 Linux 계정 암호와, CUBRID DB 계정인 dba 의 암호를 입력한다. 처음 CUBRID 설치 후 dba 암호를 변경하지 않았을 경우, dba 암호의 입력 없이 <Enter> 키를 누르면 된다.

   HA/replica cubrid_usr's password :
   HA/replica cubrid_usr's password :
   
   testdb's DBA password :
   Retype testdb's DBA password :
   

2. 레플리카 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   ##### step 2 ###################################################################
   #
   #  ha_make_slavedb.sh is the script for making slave database more easily
   #
   #  * environment
   #   - db_name           : testdb
   #
   #   - master_host       : nodeA
   #   - slave_host        : nodeB
   #   - replica_hosts     : nodeC nodeD
   #
   #   - current_host      : nodeD
   #   - current_state     : replica
   #
   #   - target_host       : nodeC
   #   - target_state      : replica
   #
   #   - repl_log_home     : /home/cubrid_usr/CUBRID/databases
   #   - backup_dest_path  : /home/cubrid_usr/.ha/backup
   #   - backup_option     :
   #   - restore_option    :
   #
   #  * warning !!!
   #   - environment on slave must be same as master
   #   - database and replication log on slave will be deleted
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

3. 대상 레플리카 노드의 HA 관련 스크립트들을 마스터 노드에 복사하는 단계이다. 질문에 y를 입력한다. 이후 모든 단계에서도 마스터 노드에 접속 시 암호를 요구하게 되며, scp 명령을 이용하여 필요한 파일을 전송할 때에도 암호를 요구한다.

   ##### step 3 ###################################################################
   #
   #  copy scripts to master node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeA(master).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

4. 대상 레플리카 노드의 HA 관련 스크립트들을 슬레이브 노드에 복사하는 단계이다.

   ##### step 4 #####################################
   #
   #  copy scripts to slave node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeB().
   #
   ##################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

5. 대상 레플리카 노드의 HA 관련 스크립트들을 원본 레플리카 노드에 복사하는 단계이다.

   ##### step 5 ###################################################################
   #
   #  copy scripts to target node
   #
   #  * details
   #   - scp scripts to '~/.ha' on nodeC(replica).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

6. 모든 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   expect 명령이 설치(root 계정에서 yum install expect)되어 있지 않으면 이 단계에서 오류가 발생할 수 있다.

   ##### step 6 ###################################################################
   #
   #  check environment of all ha nodes
   #
   #  * details
   #   - test $CUBRID == /home1/cubrid_usr/CUBRID
   #   - test $CUBRID_DATABASES == /home1/cubrid_usr/CUBRID/database
   #   - test -d /home1/cubrid_usr/CUBRID/database/testdb
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

7. HA 복제 재구축을 위해 원본 노드(target_host)로부터 백업 볼륨을 생성하는 단계로서, 기존에 이미 생성한 백업 볼륨이 있다면 s를 입력하여 다음 단계로 넘어갈 수 있다. 기존 백업 볼륨을 사용하여 복제 재구축을 수행하기 위해서는 다음과 같은 제약 조건이 있다.

   • 백업 시작 이후 생성된 보관 로그(archive logs), 원본 DB에 미반영된 복제 로그와 복제 재구축 이후 진행 중인 트랜잭션에 대한 복제 로그가 반드시 원본 레플리카 노드(target_host) 내에 존재해야 한다(즉, 오래 전에 생성한 백업 볼륨은 사용할 수 없음).
   • 백업 시 -o 옵션을 사용하여 백업 상태 정보 파일을 남겨야 한다. 이때 저장되는 경로는 백업 볼륨 파일의 경로와 같아야 한다. 파일 이름은 db_name.bkup.output 형식이어야 하며, 파일 이름이 다른 경우 스크립트 수행 전에 형식에 맞게 변경한다.
   • 기존 백업 볼륨 및 상태 정보 파일의 경로는 스크립트 내의 backup_dest_path 파라미터에 지정해야 한다. 즉, 원본 노드(target_host)에 존재하는 백업 볼륨이 포함된 디렉터리의 절대 경로를 이 파라미터에 지정하면 된다.

   ##### step 7 ###################################################################
   #
   #  online backup database  on replica
   #
   #  * details
   #   - run 'cubrid backupdb -C -D ... -o ... testdb@localhost' on replica
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

8. 원본 레플리카 노드의 데이터베이스 백업본을 대상 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

   ##### step 8 ###################################################################
   #
   #  copy testdb databases backup to current host
   #
   #  * details
   #   - scp databases.txt from target host if there's no testdb info on current host
   #   - remove old database and replication log if exist
   #   - make new database volume and replication path
   #   - scp  database backup to current host
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

9. 복사한 데이터베이스 백업본을 대상 레플리카 노드에 복구하는 단계이다. 질문에 y를 입력한다.

   ##### step 9 ###################################################################
   #
   #  restore database testdb on current host
   #
   #  * details
   #   - cubrid restoredb -B ... testdb current host
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

10. 복제 원본 레플리카 노드의 복제를 중단하는 단계이다. 질문에 y를 입력한다.

    ##### step 10 ###################################################################
    #
    #  suspend copylogdb/applylogdb on target server if running
    #
    #  * details
    #   - deregister copylogdb/applylogdb on nodeC(replica).
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

11. 원본 레플리카 노드에 있는 복제 로그를 초기화하고, 원본 레플리카 노드의 보관 로그를 대상 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 11 ###################################################################
    #
    #  make initial replication active log on target, and copy archive logs from
    #  target
    #
    #  * details
    #   - remove old replication log on target if exists
    #   - start copylogdb to make replication active log
    #   - copy archive logs from target
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

12. 원본 레플리카 노드의 복제를 재구동한다.

    ##### step 12 ###################################################################
    #
    #  restart copylogdb/applylogdb on target
    #
    #  * details
    #   - restart copylogdb/applylogdb
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

13. 레플리카 노드 구축이 정상적으로 완료되었는지 여부를 출력하는 단계이다.

    ##### step 13 ##################################################################
    #
    #  completed
    #
    ################################################################################
    

ha_make_slavedb.sh 스크립트의 수행이 완료되면 다음 작업을 수행한다.

• nodeD를 새로 구축하는 경우 nodeA, nodeB, nodeC에서 변경된 cubrid_ha.conf의 ha_node_list, ha_replica_list를 적용한다.

  [nodeA]$ cubrid heartbeat reload
  

  [nodeB]$ cubrid heartbeat reload
  

  [nodeC]$ cubrid heartbeat reload
  

• nodeC에서 log_max_archives 설정을 cubrid.conf에 지정된 값으로 재설정한다.

  [nodeC]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=0'" testdb@localhost
  

• nodeD에서 HA 상태를 확인하고, cubrid heartbeat start 명령으로 HA를 구동한다.

  [nodeD]$ cubrid hb status
  @ cubrid heartbeat status
  
   HA-Node Info (current nodeD, state unknown)
  
  
   HA-Process Info (master 5214, state unknown)
  
  [nodeD]$ cubrid hb start
  @ cubrid heartbeat start
  @ cubrid master start
  ++ cubrid master is running.
  @ HA processes start
  @ cubrid server start: testdb
  
  This may take a long time depending on the amount of recovery works to do.
  
  CUBRID 9.2
  
  ++ cubrid server start: success
  @ copylogdb start
  ++ copylogdb start: success
  @ applylogdb start
  ++ applylogdb start: success
  ++ HA processes start: success
  ++ cubrid heartbeat start: success
  
  [nodeD]$ cubrid hb status
  @ cubrid heartbeat status
  
   HA-Node Info (current nodeD, state replica)
     Node nodeD (priority 32767, state replica)
     Node nodeC (priority 32767, state replica)
     Node nodeB (priority 2, state slave)
     Node nodeA (priority 1, state master)
  
  
   HA-Process Info (master 5214, state slave)
     Applylogdb testdb@nodeB:/home1/cubrid_usr/CUBRID/databases/testdb_nodeB (pid 5816, state registered)
     Applylogdb testdb@nodeA:/home1/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 5814, state registered)
     Copylogdb testdb@nodeB:/home1/cubrid_usr/CUBRID/databases/testdb_nodeB (pid 5812, state registered)
     Copylogdb testdb@nodeA:/home1/cubrid_usr/CUBRID/databases/testdb_nodeA (pid 5810, state registered)
     Server testdb (pid 5590, state registered_and_standby)
  

• cubrid_broker.conf를 참고하여 브로커를 설정하고, "cubrid broker restart" 명령으로 브로커를 구동한다.

레플리카에서 슬레이브 구축¶

다음은 복제 재구축 원본 노드를 레플리카 노드로 하여, 레플리카 노드에서 슬레이브 노드를 새로 구축하거나 재구축하는 예이다. 새로 구축하는 경우 Master:Slave:Replica는 1:0:2에서 1:1:2가 된다.

ha_make_slavedb.sh 스크립트를 사용하는 경우, 재구축 이후에 슬레이브 노드는 하나만 존재해야 한다.

• 마스터 노드 호스트 명: nodeA
• 슬레이브 노드 호스트 명: nodeB
• 레플리카 노드 호스트 명: nodeC
• 레플리카 노드 호스트 명: nodeD

복제 재구축은 시스템이 운영 중인 상태에서도 수행할 수 있으나, 복제 지연을 최소화하기 위해 시간 당 트랜잭션 수가 적을 때 수행하는 것을 권장한다.

ha_make_slavedb.sh 스크립트를 실행하기 전에 다음을 수행한다.

1. nodeB의 HA 서비스를 종료한다. nodeB를 새로 구축한다면 이 과정은 불필요하다.

   [nodeB]$ cubrid heartbeat stop
   [nodeB]$ cubrid service stop
   

2. nodeB를 새로 구축한다면 환경 설정을 참고하여 nodeA, nodeB, nodeC, nodeD의 cubrid.conf, cubrid_ha.conf, cubrid_broker.conf, databases.txt를 설정해야 한다.

   • nodeB의 cubrid.conf에 설정

     ha_mode=on
     

   • 모든 노드의 cubrid_ha.conf에 설정

     ha_node_list=cubrid@nodeA:nodeB
     ha_replica_list=cubrid@nodeC:nodeD
     

   • 모든 노드에서 databases.txt의 db-host 설정

     nodeA:nodeB:nodeC:nodeD
     

     하지만 databases.txt의 db-host 부분은 브로커에서 DB 서버로의 접속 순서와 관련된 설정이므로 원하는대로 변경이 가능하다.

3. nodeC에 DB의 재구동 없이 log_max_archives의 변경된 값을 적용한다.

   레플리카 구축 시간 동안 수행되는 트랜잭션을 보관할 수 있는 보관 로그(archive logs) 개수를 10이라고 가정한다. "SET SYSTEM PARAMETERS" 문을 사용하여 "10"으로 설정하며, cubrid.conf의 log_max_archives는 nodeB의 구축/재구축 이후 기존 설정을 사용할 것이므로 변경하지 않는다.

   [nodeC]$ csql -u dba -c "SET SYSTEM PARAMETERS 'force_remove_log_archives=no'" testdb@localhost
   [nodeC]$ csql -u dba -c "SET SYSTEM PARAMETERS 'log_max_archives=10'" testdb@localhost
   

4. nodeB의 ha_make_slavedb.sh 스크립트를 설정해야 한다. target_host에는 복사할 원본, 즉 nodeB를 설정하고, repl_log_home에는 복제 로그의 홈 디렉터리(기본값: $CUBRID_DATABASES)를 설정한다.

   [nodeB]$ cd $CUBRID/share/scripts/ha
   [nodeB]$ vi ha_make_slavedb.sh
   target_host=nodeC
   

5. 설정 후에는 nodeB에서 ha_make_slavedb.sh 스크립트를 실행한다.

   [nodeB]$ cd $CUBRID/share/scripts/ha
   [nodeB]$ ./ha_make_slavedb.sh
   

ha_make_slavedb.sh 스크립트를 각 단계의 순서대로 실행하는 도중 오류가 발생하거나 n을 입력하여 실행을 중단한 이후에 재실행할 경우, 그 이전까지 실행에 성공한 단계에 대해서는 s를 입력하여 다음 단계로 넘어가도 된다.

1. HA 복제 재구축을 위한 Linux 계정의 암호와, CUBRID DB 계정인 dba 의 암호를 입력하는 단계이다. 질문에 y를 입력한다.

   ##### step 1 ###################################################################
   #
   # get HA/replica user password and DBA password
   #
   #  * warning !!!
   #   - Because ha_make_slavedb.sh uses expect (ssh, scp) to control HA/replica node,
   #     the script has to know these passwords.
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

   HA 노드의 Linux 계정 암호와, CUBRID DB 계정인 dba 의 암호를 입력한다. 처음 CUBRID 설치 후 dba 암호를 변경하지 않았을 경우, dba 암호의 입력 없이 <Enter> 키를 누르면 된다.

   HA/replica cubrid_usr's password :
   HA/replica cubrid_usr's password :
   
   testdb's DBA password :
   Retype testdb's DBA password :
   

2. 슬레이브 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   ##### step 2 ###################################################################
   #
   #  ha_make_slavedb.sh is the script for making slave database more easily
   #
   #  * environment
   #   - db_name           : testdb
   #
   #   - master_host       : dhtest001.ncl
   #   - slave_host        : test-dhlee002.ncl
   #   - replica_hosts     : test-dhlee004.ncl test-dhlee005.ncl
   #
   #   - current_host      : test-dhlee002.ncl
   #   - current_state     : slave
   #
   #   - target_host       : test-dhlee004.ncl
   #   - target_state      : replica
   #
   #   - repl_log_home     : /home1/cubrid/CUBRID/databases
   #   - backup_dest_path  : /home1/cubrid/.ha/backup
   #   - backup_option     :
   #   - restore_option    :
   #
   #  * warning !!!
   #   - environment on slave must be same as master
   #   - database and replication log on slave will be deleted
   #
   ################################################################################
   
       continue ? ([y]es / [n]o / [s]kip) : y
   

3. 슬레이브 노드의 HA 관련 스크립트들을 마스터 노드에 복사하는 단계이다. 질문에 y를 입력한다. 이후 scp 명령을 이용하여 필요한 파일을 전송할 때 ssh-keygen으로 공개 키를 설정하지 않았으면 암호를 요구한다.

   ##### step 3 ###################################################################
   #
   #  copy scripts to master node
   #
   #  * details
   #   - scp scripts to '~/.ha' on dhtest001.ncl(master).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

4. HA 관련 스크립트들을 레플리카 노드에 복사하는 단계이다. 질문에 y를 입력한다.

   ##### step 4 ###################################################################
   #
   #  copy scripts to replication node
   #
   #  * details
   #   - scp scripts to '~/.ha' on replication node.
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

5. 모든 노드의 환경 변수 설정이 올바른지 확인하는 단계이다. 질문에 y를 입력한다.

   expect 명령이 설치(root 계정에서 yum install expect)되어 있지 않으면 이 단계에서 오류가 발생할 수 있다.

   ##### step 5 ###################################################################
   #
   #  check environment of all ha nodes
   #
   #  * details
   #   - test $CUBRID == /home1/cubrid/CUBRID
   #   - test $CUBRID_DATABASES == /home1/cubrid/CUBRID/databases
   #   - test -d /home1/cubrid/CUBRID/databases
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

6. 마스터 노드의 복제를 중단하는 단계이다. 질문에 y를 입력한다.

   ##### step 6 ###################################################################
   #
   #  suspend copylogdb/applylogdb on master if running
   #
   #  * details
   #   - deregister copylogdb/applylogdb on dhtest001.ncl(master).
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

7. 이전에 슬레이브 노드에 존재했던 오래된 복제 로그를 삭제하고 마스터 노드의 HA 메타 정보 테이블을 초기화하는 단계이다. 질문에 y를 입력한다.

   ##### step 7 ###################################################################
   #
   #  remove old copy log of slave and init db_ha_apply_info on master
   #
   #  * details
   #   - remove old copy log of slave
   #   - init db_ha_apply_info on master
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

8. 레플리카 노드의 HA 메타 정보 테이블을 초기화하는 단계이다. 이 시나리오에서는 레플리카 노드가 없으므로 질문에 s를 입력하여 넘어가도 된다.

   ##### step 8 ###################################################################
   #
   #  remove old copy log of slave and init db_ha_apply_info on replications
   #
   #  * details
   #   - remove old copy log of slave
   #   - init db_ha_apply_info on replications
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

9. HA 복제 재구축을 위해 레플리카 노드(target_host)로부터 백업 볼륨을 생성하는 단계로서, 기존에 이미 생성한 백업 볼륨이 있다면 s를 입력하여 다음 단계로 넘어갈 수 있다. 기존 백업 볼륨을 사용하여 복제 재구축을 수행하기 위해서는 다음과 같은 제약 조건이 있다.

   • 백업 시 실행 중인 트랜잭션을 포함하는 보관 로그(archive logs)가 반드시 레플리카 노드(target_host) 내에 존재해야 한다(즉, 오래 전에 생성한 백업 볼륨은 사용할 수 없음).
   • 백업 시 -o 옵션을 사용하여 백업 상태 정보 파일을 남겨야 한다. 이때 저장되는 경로는 백업 볼륨 파일의 경로와 같아야 한다. 파일 이름은 db_name.bkup.output 형식이어야 하며, 파일 이름이 다른 경우 스크립트 수행 전에 형식에 맞게 변경한다.
   • 기존 백업 볼륨 및 상태 정보 파일의 경로는 스크립트 내의 backup_dest_path 파라미터에 지정해야 한다. 즉, 레플리카 노드(target_host)에 존재하는 백업 볼륨이 포함된 디렉터리의 절대 경로를 이 파라미터에 지정하면 된다.

   ##### step 9 ###################################################################
   #
   #  online backup database  on replica
   #
   #  * details
   #   - run 'cubrid backupdb -C -D ... -o ... testdb@localhost' on replica
   #
   ################################################################################
   
      continue ? ([y]es / [n]o / [s]kip) : y
   

10. 레플리카 노드의 데이터베이스 백업본을 슬레이브 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 10 ###################################################################
    #
    #  copy testdb databases backup to current host
    #
    #  * details
    #   - scp databases.txt from target host if there's no testdb info on current host
    #   - remove old database and replication log if exist
    #   - make new database volume and replication path
    #   - scp  database backup to current host
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

11. 복사한 데이터베이스 백업본을 슬레이브 노드에 복구하는 단계이다. 질문에 y를 입력한다.

    ##### step 11 ###################################################################
    #
    #  restore database testdb on current host
    #
    #  * details
    #   - cubrid restoredb -B ... testdb current host
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

12. 마스터에 있는 복제 로그를 초기화하고, 마스터 노드의 보관 로그를 슬레이브 노드에 복사하는 단계이다. 질문에 y를 입력한다.

    ##### step 12 ###################################################################
    #
    #  make initial replication active log on master, and copy archive logs from
    #  master
    #
    #  * details
    #   - remove old replication log on master if exist
    #   - start copylogdb to make replication active log
    #   - copy archive logs from master
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

13. 마스터 노드의 복제를 재시작하는 단계이다. 질문에 y를 입력한다.

    ##### step 13 ###################################################################
    #
    #  restart copylogdb/applylogdb on master
    #
    #  * details
    #   - restart copylogdb/applylogdb
    #
    ################################################################################
    
       continue ? ([y]es / [n]o / [s]kip) : y
    

14. 슬레이브 노드 구축이 정상적으로 완료되었는지 여부를 출력하는 단계이다.

    ##### step 14 ##################################################################
    #
    #  completed
    #
    ################################################################################
    

ha_make_slavedb.sh 스크립트의 수행이 완료되면 다음 작업을 수행한다.

• 슬레이브 노드에서 HA 상태를 확인하고, cubrid heartbeat start 명령으로 HA를 구동한다.

  [NodeB]$ cubrid heartbeat status
  @ cubrid heartbeat status
  ++ cubrid master is not running.
  
  [NodeB]$ cubrid heartbeat start
  @ cubrid heartbeat start
  @ cubrid master start
  ++ cubrid master start: success
  @ HA processes start
  @ cubrid server start: testdb
  
  This may take a long time depending on the amount of recovery works to do.
  
  CUBRID 9.2
  
  ++ cubrid server start: success
  @ copylogdb start
  ++ copylogdb start: success
  @ applylogdb start
  ++ applylogdb start: success
  ++ HA processes start: success
  ++ cubrid heartbeat start: success
  
  [NodeB]$ cubrid hb status
  @ cubrid heartbeat status
  
   HA-Node Info (current test-dhlee002.ncl, state slave)
     Node nodeD (priority 32767, state replica)
     Node nodeC (priority 32767, state replica)
     Node nodeB(priority 2, state slave)
     Node nodeA (priority 1, state master)
  
  
   HA-Process Info (master 27221, state slave)
     Applylogdb testdb@nodeA:/home1/cubrid/CUBRID/databases/testdb_nodeA (pid 27455, state registered)
     Copylogdb testdb@nodeA:/home1/cubrid/CUBRID/databases/testdb_nodeA (pid 27453, state registered)
     Server testdb (pid 27228, state registered_and_standby)
  

cubrid_broker.conf를 참고하여 브로커를 설정하고, cubrid broker restart 명령으로 브로커를 구동한다.